Hi Folks - I’m now looking at the move to SVN with ProjectLocker and Subversion and was wondering what others are doing for table and data syncing for the back-end during development?
I was thinking that hosting the Db on a remote server for access by all developers might be a solution but that just adds more wrinkles and chances for slow connections etc. Second thoughts were simply to do a SQL Dump after any structural or data changes that might effect other developers - error prone though I fear!
BTW I’m looking at going to Sybase for the back-end now too - if that might influence how we’d do this syncing.
Structure changes can be made using the Problems list and/or syncing with the database information (dbi) files after an update. Any structure changes will be identified after syncing the resources file. Since the dbi file will change after SVN update (if there is a db change, that is), you can right click on Database Server and select “Synchronize with DB server information”.
Data changes are a different story, if the data changes are important, a sql dump or using a shared database connection will be required. If you are using SQL Anywhere and are interesting in keeping your developers in local databases, you may look into a Mobilink syncing solution as well. Sybase Central has wizards for setting up Mobilink.
Just one gotcha…
When you DO use shared connections (i.e. a single DB) then you should keep in mind that when you use Servoy Sequences you are bound to get in a world of hurt. Why?
When you work in Developer you are in fact working from your workspace and not from any repository database (local or shared). All Servoy objects live in your workspace, including the tracking of your Servoy sequences. So when you have 2 or more developers then there are 2 or more places where sequences are kept.
So for instance when you use a shared i18n database with a bunch of developers you should change that database (and your Servoy table settings) to database managed sequences or agree that always 1 specific developer makes the changes (mainly the inserts).
jmeunier:
Structure changes can be made using the Problems list and/or syncing with the database information (dbi) files after an update. Any structure changes will be identified after syncing the resources file. Since the dbi file will change after SVN update (if there is a db change, that is), you can right click on Database Server and select “Synchronize with DB server information”.
Data changes are a different story, if the data changes are important, a sql dump or using a shared database connection will be required. If you are using SQL Anywhere and are interesting in keeping your developers in local databases, you may look into a Mobilink syncing solution as well. Sybase Central has wizards for setting up Mobilink.
Hope this helps.
Jason
That’s kind of what I was hoping to hear Jason thanks.
ROCLASI:
Just one gotcha…
When you DO use shared connections (i.e. a single DB) then you should keep in mind that when you use Servoy Sequences you are bound to get in a world of hurt. Why?
When you work in Developer you are in fact working from your workspace and not from any repository database (local or shared). All Servoy objects live in your workspace, including the tracking of your Servoy sequences. So when you have 2 or more developers then there are 2 or more places where sequences are kept.
So for instance when you use a shared i18n database with a bunch of developers you should change that database (and your Servoy table settings) to database managed sequences or agree that always 1 specific developer makes the changes (mainly the inserts).
Hope this helps.
That’s actually good and bad news Robert. Good in that we can remodel our solution tables to use Db specific sequences, but bad in the fact that I had originally intended that Servoy keep the sequences so we would be truly Db Agnostic.
I think we need to reconsider this. Jasons suggestions above seem like the correct direction, where we share structural updates through SVN and regularly use SQLDump for data updates (mainly 1 developer doing data changes but more than 1 may need to generate test data for development forms etc.).
Obviously this will still entail Db managed sequences.
Kahuna:
Good in that we can remodel our solution tables to use Db specific sequences…
Well if you mean with solution tables the tables in the repository then you can’t. Only tables outside the Servoy repository you can refractor to use db sequences like the i18n table I mentioned.
Kahuna:
I think we need to reconsider this. Jasons suggestions above seem like the correct direction, where we share structural updates through SVN and regularly use SQLDump for data updates (mainly 1 developer doing data changes but more than 1 may need to generate test data for development forms etc.).
Obviously this will still entail Db managed sequences.
You can still use servoy sequences with this scenario. You just need to sync your own sequences with the database after you restored the SQL dump.
(right-click on the connection name in the ‘database servers’ node and select ‘update servoy sequences’)
Kahuna:
Good in that we can remodel our solution tables to use Db specific sequences…
Well if you mean with solution tables the tables in the repository then you can’t. Only tables outside the Servoy repository you can refractor to use db sequences like the i18n table I mentioned.
Kahuna:
I think we need to reconsider this. Jasons suggestions above seem like the correct direction, where we share structural updates through SVN and regularly use SQLDump for data updates (mainly 1 developer doing data changes but more than 1 may need to generate test data for development forms etc.).
Obviously this will still entail Db managed sequences.
You can still use servoy sequences with this scenario. You just need to sync your own sequences with the database after you restored the SQL dump.
(right-click on the connection name in the ‘database servers’ node and select ‘update servoy sequences’)
Hope this helps.
Excellent thanks Robert - great feedback as always.