Tracks

Hi,

I’ve discovered Tracks and love it. I’m currently comparing it to What’s Next. Anyway, one of the requirements (or at least hopes) for this to work for me is to be able to seamlessly access my data whether at my desk (I have a dedicated desktop station) or from away (I also have a laptop which may be on the network or vpn’d in from home).

I work at a company developing technology and storing my database (or all of tracks for that matter) on a webhost is just not an option due to the Intellectual Property issues of what will be contained.

Here’s my vision:
- the main computer hosting the server will be my desktop station
—- I can access tracks from either the desktop (http://localhost) or laptop (http://desktop-ip) when it is up
- when the desktop is off or I’m home I can start up the server on my laptop to see tracks
- the database is seamlessly shared between the two
—- the ideal for this would be to keep the database on my allotted network share drive. This seems like it should be very easy to do.

Currently I’ve tried editing database.yml to edit the development environment to look like this:

The folder ‘tracks’ actually only has the folder ‘db’ inside of it.

I get a ‘500 Internal Server Error’ when I do this.

Any thoughts?
- is it just editing another file?
- do I need to copy more than the db folder to my network share?

Please let me know if any other information would be helpful.

Best regards,
John

be aware that this setup is not supported I think you can have synchronization errors when you work in tracks on both the desktop and the (off-line) laptop

The 500 message is generic. So check your tracks log for details.

I’ve not had problems running the server on my desktop and then plugging in the desktop ip from my laptop in a browser and having it work. I guess I have not seen whether there are long term issues. At present.

This is more of a question of how to store a tracks database somewhere other than ./tracks-1.7/db/db_name.db. My main question is what else I have to update to make this work. I tried simply accessing the database stored on a windows share by changing the db location in database.yml. This did not work. Is there something else to do?

John

this should normally work

are you using \\server\share, i.e. windows network or are you using unix-like mountpoint?

AFAIK, only local directories (local drives on windows) are supported…

Setup:

- Tracks on desktop
- Windows share \\server-ip\username type
- Win share mounted at local directory on desktop using (in fstab):
—- //server-ip/username   /media/h   cifs   user=username,noauto 0 0

What did not work for me:
- logout of tracks session
- ctrl-c to quit running server
- count to 10
- cp ~/tracks-1.7/db/tracks-17-blank.db /media/h/tracks/db/tracks-17-blank.db
- nano ~/tracks-1.7/config/database.yml
—- edit production section
—- database: /media/h/tracks/db/tracks-17-blank.db
- cd ~/tracks-1.7
- script/server -e production
- go to localhost:3000
- got (this time… maybe I did something wrong the last time):

If I try going to localhost:3000/logout, I got a bunch of error lines. Then I copied the errors above and tried to go back to the logout page and got 500 Internal Server Error. When I switch back to the local database (via database.yml) and restart the server, I initially get the database is locked message but simply going to localhost:3000/logout gets me to the login again…

I’m guessing something’s just wrong with the database staying locked, it not being in the right folder, having a keygen somewhere not work right??

Thanks for the help,
John

maybe a stupic question, but is the network share read-write? or only read?

Read-write. Not a stupid question, though The fstab does not explicitly have rw in the options, but it’s my personal share drive for the company and I access and save files from it regularly.

Would I need rw explicitly in fstab for Tracks to access a db?

in your database.yml quote you use the development section. But in the cp statement above, you copy the production database. Could this be the problem?

No, rw is not necessary if you can write to the share.

What bothers me is that when you switch back to the local .db the lock is also there. I’m suspecting a corrupt database. I’m not that familiar with sqlite, but there are command to check and repair databases.

I quickly googled around and found “PRAGMA integrity_check;”  you can run it from sqlite3 <your db> from the command line

Originally, yes, I was trying to use the development settings as not to goof things with production by accident. Then I just switched to changing production settings back and forth in case it was something with development I was unaware of.

Doing:
- sqlite3 ~/tracks/db/tracks-17-blank.db
> PRAGMA integrity_check;

Returns:
>ok

The lockout when returning back to the local copy is very quick. I woudn’t be surprised if it is just the browser not refreshing itself from messing with the remote one that was not working. All it takes is to go to localhost:3000/logout and I’m at the login prompt immediately. Doing that with the same error on the remote copy got me a ton of errors on the first attempt and then ‘500 itnernal server error’ on the second.

John

hmm, are you running passenger? or fcgi? It could be that there are several threads using the database? Especially on network shares, database accesses could be expensive, which could explain that it is more severe on that setup. So maybe the locking error is coming from there? You can try a larger timeout in database.yml and see if it works better (less or no lock errors)

That could be… I tried copying the entire tracks folder to the remote drive and starting it from there and it did not like that… should I do a ‘rake db:migrate’ from the remote drive? I’m not familiar with what db:migrate actually does. Maybe I should create a fresh database from the example and retry some things.

John

running from a network share is very slow

db:migrate will update the database structure if needed. Only applicable if you upgrade to a newer version of tracks that includes updates to the database structure.

In database.yml you can change

production:
      <...>
      adapter: sqlite3
      timeout: 5000

No dice. Database locked error again. No worries Im’ pretty happy with this setup.

One last question—if I copied the tracks db to another computer with the exact same settings, would it work for me? Say I was going out of town—could I just copy over the tracks-17-blank.db in to the ~/tracks/db folder of my laptop and it would work?

I believe I had troubles with this, too, but am not positive. I’ll try to day and post back—it seems like it should work.

Thanks for all your help,
John

yes it should work, same goes for putting the db on a usb-stick and plug it into the machine you are going to use