Tracks is awesome.  I used it w/ MySQL for a year and it helped me get a lot done.  Recently I wanted to use SQLite3 instead and here’s where the troubles begin.

I followed instructions from both the Trac site and the installation.html file included in Tracks but no matter what I do I keep getting a ‘no such file to load - sqlite3’ when I start the server.

However I can run migrations just fine to set up the schema so I’m confused—unfortunately, I’m a weak Ruby coder so I am unable to solve this myself.

I’m not at my home cpu (os x 10.4) so I can’t post the stack trace, but the above message is etched in my head from searching all over Google for an answer—which I can’t find.

I’m on Ruby 1.8.6 and Rails 2.0.2 with the proper sqlite-ruby gem installed—though this shouldn’t affect Tracks as it was probably frozen, correct?

Anyway, I don’t suppose someone would be willing to walk me through a fresh install of Tracks (tag = current) on OS X 10.4 w/ SQLite3?  I’m sure I can’t be the only one having this problem.

Thank you for the consideration and an excellent piece of software!

OS X 10.4 (non-locomotive)

$ which sqlite3
>> /usr/bin/sqlite3

$ gem query—local
>> rails (2.0.2)
>> sqlite3-ruby (1.2.1)

Then, after following the installation instructions and running a successful migration, starting the WEBrick and navigating to root route results in:

No such file to load—sqlite3
./script/../config/../vendor/rails/activesupport/lib/active_support/dependencies.rb:136:in `require’
./script/../config/../vendor/rails/activesupport/lib/active_support/dependencies.rb:136:in `require’
./script/../config/../vendor/rails/activesupport/lib/active_support/core_ext/kernel/requires.rb:7:in `require_library_or_gem’
./script/../config/../vendor/rails/activesupport/lib/active_support/core_ext/kernel/requires.rb:5:in `silence_warnings’
./script/../config/../vendor/rails/activesupport/lib/active_support/core_ext/kernel/requires.rb:5:in `require_library_or_gem’
./script/../config/../vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:14:in `sqlite3_connection’
./script/../config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:251:in `send’
./script/../config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:251:in `connection_without_query_cache=‘
./script/../config/../vendor/rails/activerecord/lib/active_record/query_cache.rb:54:in `connection=‘
./script/../config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:220:in `retrieve_connection’
./script/../config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:78:in `connection’
./script/../config/../vendor/rails/activerecord/lib/active_record/base.rb:696:in `columns’
./script/../config/../vendor/rails/activerecord/lib/active_record/base.rb:704:in `columns_hash’
./script/../config/../vendor/rails/actionpack/lib/action_controller/session/active_record_store.rb:103:in `setup_sessid_compatibility!‘
./script/../config/../vendor/rails/actionpack/lib/action_controller/session/active_record_store.rb:77:in `find_by_session_id’
./script/../config/../vendor/rails/actionpack/lib/action_controller/session/active_record_store.rb:281:in `initialize’
./script/../config/../vendor/rails/actionpack/lib/action_controller/session/active_record_store.rb:281:in `silence’
./script/../config/../vendor/rails/actionpack/lib/action_controller/session/active_record_store.rb:281:in `initialize’
/usr/lib/ruby/1.8/cgi/session.rb:273:in `new’
/usr/lib/ruby/1.8/cgi/session.rb:273:in `initialize’
./script/../config/../vendor/rails/actionpack/lib/action_controller/cgi_process.rb:111:in `new’
./script/../config/../vendor/rails/actionpack/lib/action_controller/cgi_process.rb:111:in `session’
./script/../config/../vendor/rails/actionpack/lib/action_controller/cgi_process.rb:107:in `stale_session_check!‘
./script/../config/../vendor/rails/actionpack/lib/action_controller/cgi_process.rb:107:in `session’
./script/../config/../vendor/rails/actionpack/lib/action_controller/base.rb:885:in `assign_shortcuts_without_flash’
./script/../config/../vendor/rails/actionpack/lib/action_controller/flash.rb:141:in `assign_shortcuts’
./script/../config/../vendor/rails/actionpack/lib/action_controller/base.rb:373:in `process_without_filters’
./script/../config/../vendor/rails/actionpack/lib/action_controller/filters.rb:364:in `process_without_session_management_support’
./script/../config/../vendor/rails/actionpack/lib/action_controller/session_management.rb:117:in `process’
./script/../config/../vendor/rails/railties/lib/dispatcher.rb:38:in `dispatch’
./script/../config/../vendor/rails/railties/lib/webrick_server.rb:115:in `handle_dispatch’
./script/../config/../vendor/rails/railties/lib/webrick_server.rb:81:in `service’
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service’
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run’
/usr/lib/ruby/1.8/webrick/server.rb:155:in `start_thread’
/usr/lib/ruby/1.8/webrick/server.rb:144:in `start’
/usr/lib/ruby/1.8/webrick/server.rb:144:in `start_thread’
/usr/lib/ruby/1.8/webrick/server.rb:94:in `start’
/usr/lib/ruby/1.8/webrick/server.rb:89:in `each’
/usr/lib/ruby/1.8/webrick/server.rb:89:in `start’
/usr/lib/ruby/1.8/webrick/server.rb:79:in `start’
/usr/lib/ruby/1.8/webrick/server.rb:79:in `start’
./script/../config/../vendor/rails/railties/lib/webrick_server.rb:67:in `dispatch’
./script/../config/../vendor/rails/railties/lib/commands/servers/webrick.rb:59
./script/../config/../vendor/rails/activesupport/lib/active_support/dependencies.rb:136:in `require’
./script/../config/../vendor/rails/activesupport/lib/active_support/dependencies.rb:136:in `require’
./script/../config/../vendor/rails/railties/lib/commands/server.rb:30
script/server:3:in `require’
script/server:3

—please advise—

I can’t immediately see why there’s a problem here. You do indeed need the SQLite3 gem installed because it needs to be compiled for the platform it runs on, I believe, like the MySQL gem.

It’s very odd that you can run the migration to set the structure up, but it then fails to connect to the db when you run the server. One thing to double check is that you have the correct path to the database, and correct database name in both the development and production sections of database.yml. By default, migrations use development mode, as does script/server without any arguments, but it would be good to double check that. I also once made a typo in my db name in database.yml, and it took me ages to work out why it wasn’t working!

I assume that you’ve used the SQLite3 tool itself to check that the migration did indeed set up the tables correctly?

Note also that there is no tracks under the tag current yet: I’ve added that to the manual in trunk for preparation for the release of 1.5. You want the following command if you want the trunk rather than the stable 1.043:

svn co—username=guest http://www.rousette.org.uk/svn/tracks-repos/trunk/tracks

Anyway, double check the paths as suggested above, and get back to us if you don’t have any luck.

Hi, bsag,

Thank you for the timely and spot-on reply.  I was doing at least two things wrong:

1) I was creating a new SQLite file instead of using the pre-provided one
2) I was using the wrong file name in the database.yml file

Now, all systems are go and I’m relieved to have my tasks off my mind and in my list.

Thanks go to you and all the Tracks contributors.

Best

Looks like my previous celebratory post was premature.  Tracks is now running in development mode (with the pre-provided tracks-1041.db) and I can navigate to the Login screen.  However, when I try to login as: admin password: abracadabra I get a message:

########
Status: 500 Internal Server Error Content-Type: text/html
Application error (Apache)

Change this error message for exceptions thrown outside of an action (like in Dispatcher setups or broken Ruby code) in public/500.html
########

I also get the same message when navigating to localhost:3000/signup

From here, I tried deleting the .db file and rake db:migrate a new one, but the migration fails:

########
== AddUserId: migrating =======================================================
—add_column(:contexts, :user_id, :integer, {:default=>1})
rake aborted!
SQLite3::SQLException: near “ADD”: syntax error: ALTER TABLE contexts ADD “user_id” integer DEFAULT 1
########

When I first started the server, I received the following:

########
=> Booting Mongrel (use ‘script/server webrick’ to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment…
** has_many_polymorphs: rails environment detected
** has_many_polymorphs: loaded ok
SwitchEnvironmentController: missing default helper path switch_environment_helper
UnobtrusiveJavascriptController: missing default helper path unobtrusive_javascript_helper
** has_many_polymorphs: autoload hook invoked
** has_many_polymorphs: preloading parent model Tag
** has_many_polymorphs: associating Tag.taggables
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It might not work well.
** Mongrel 1.1.3 available at 0.0.0.0:3000
** Use CTRL-C to stop.
** has_many_polymorphs: WARNING; possibly critical error preloading Tag: #<ActiveRecord::StatementInvalid: ActiveRecord::StatementInvalid>
#########

I’m currently working on trunk (704)—is this worth reporting a bug over?

Any idea how to fix?  Thanks.

I keep banging my head against the wall but it still won’t work.

Steps to recreate:

1. svn co—username=guest http://www.rousette.org.uk/svn/tracks-repos/trunk tracks
>> checked out rev 711

2. cd tracks

3. change log.tmpl -> log
          environment.rb.tmpl -> environment.rb (and edit the SALT)
          database.yml.tmpl -> database.yml (edit the development db to: adapter: sqlite3
                                                                          database: tracks-1041.db

4. script/server and navigate web browser to :3000

Tracks login screen is up!  So I log in username: admin
                                    password:  abracadabra

And I get the same error I listed first in the message above.  So I script/console and u = User.find(:all) and that lists 2 users, admin and jane.  So Rails and SQLite3 are talking—is this server related?

I don’t know if this is due to my Rails version (2.0.2), Ruby (1.8.6), Gems (1.0.1), SQLite3 (3.1.3), OS X (10.4).

I’ve also tried deleting the schema.rb, provided SQLite3 dbs, and rake db:migrate a completely new db, but I still get the second error listed in the post above (migration failing).

Need help—going through withdrawal.  Thanks.

This thread’s had 600+ views but only 1 reply?  Help me out people!

Please and thank you

Hi

All I can see from your post of 23-1-2008 is that you did not run rake db:migrate between step 3 and 4.

I’ve recreated a new example sqlite database in the 1.5rc1 release of Tracks. I’ve run rake db:migrate on it. See if you can get it running with that db.

Hi, Reinier,

Thanks for the reply.  I svn’d 1.5rc1, configured as normal, attempted to run db:migrate and received this:

== AddUserId: migrating =======================================================
—add_column(:contexts, :user_id, :integer, {:default=>1})
rake aborted!
SQLite3::SQLException: near “ADD”: syntax error: ALTER TABLE contexts ADD “user_id” integer DEFAULT 1
/Users/go_suns/rails/tracks-1.5rc1/tracks/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:128:in `log’

Is this because I’m using SQLite3 instead of MySQL?

Glad to see Tracks 1.5 has finally arrived!  Hopefully I can work out my issues so I can use it.

Thanks, keep me posted.

strange, if you use the tracks-15.db from 1.5rc1 (or tracks-1.5-example.db from trunk) it should not do anything on rake db:migrate. Do you have the right path and the right filename? The path should be absolute I believe.

Reinier,

You were right…I left the db/ out of my path.  So now I can run Tracks 1.5 but I can’t figure out how to login.  I tried u: admin p: abracadabra but it doesn’t work on the example db.

I script/consoled in and saw there are 2 users already created—what’s the admin’s password?

Also, how do I create a fresh db, not the example one?  I tried just renaming the db config and the rake failed with the message I posted above.  How can I have a successful rake db:migrate with a fresh db?

So close, thanks.

Okay, I’m in, and it’s really cool.

I changed from example db (where I couldn’t find the password) to blank db and after starting the server it prompted me to create an admin account and everything’s up and running from there.  I really like the design enhancements since 1.043.

Thanks everyone for your help, I’m excited to be using this again.

go_suns: In case anyone else runs into the problem, the user/password for the example db is indeed admin/abracadabra, but it was created with the default salt (in config/envrionment.rb) of “change-me”. If you’d already changed your salt to whatever you had originally set, it wouldn’t work, I think. I need to test that, but I think that was probably the problem.

Furthermore, make sure that you have your rights set correctly. In my test setup I had svn’ed as root and tried to change the db using as another user. You get permission denied errors then

Hi, bsag,

You were absolutely correct—changing the SALT was the reason ‘abracadabra’ wasn’t working.

Reinier, I didn’t svn as root so I didn’t experience that problem but now I know to keep an eye on that for the future.

1.5 is impressive.  bsag’s wiki page explains all the new features—nice work people, thanks for the great application.