Deployment tip 101..

[david]

I want to pass along something that is probably obvious to most but caught me blind-sided. Hope it helps some newbies like me

For my setup I have been developing on one computer and serving from another which is the recommended practice.

To transfer a new revision to the server computer, I would export my solution, transfer the resulting file, import new solution, and fire up server again. Kind of clunky but not clunky enough for me to waste limited brain power to figure out a better way.

Well, now I have users putting in significant time on my little app. I put a new version in recently and it immediately threw a whole bunch of duplicate ID errors as users were trying to enter records. Went to check my auto-enter options for my key fields and they were completely off. Reason: importing a new version over-wrote the auto-increment keyfield settings on the repository for the server with the repository data from my development computer. Since people are using my app now, the next increment number on my computer is much lower than what is stored on the server.

Here's the hint part: change the repository settings on your development machine to point to the repository on your server machine (replace "localhost" with IP or domain name of your server). Not only will it keep your key fields square but you don't have to go through the export/import routine - just restart the server.

Obviously still learning some of the ropes over here

- david

[bcusick]

Hi David,

THANKS for posting your experiences! It helps all of us!

One more thing to add - in the upcoming 1.1 verion - if you change the auto-enter property of key field (sequence) to "managed by database" - you can avoid the duplicate key values and also develop on a different machine (in my case a laptop) and deploy on a different server (in my case SQL Server).

Hope this helps,

Bob Cusick

[Guest]

Well, now I have users putting in significant time on my little app. I put a new version in recently and it immediately threw a whole bunch of duplicate ID errors as users were trying to enter records. Went to check my auto-enter options for my key fields and they were completely off. Reason: importing a new version over-wrote the auto-increment keyfield settings on the repository for the server with the repository data from my development computer. Since people are using my app now, the next increment number on my computer is much lower than what is stored on the server.

Are you just exporting the solution? Or are you also moving your repository around? If you only export your solution your auto-enter values should be maintained as they are server bound.

[david]

Yes, I have been moving my server (and repository which uses the local firebird install) around a bit as well due to various things so that could very well be it instead.

Certainly developing and deploying using the same repository makes everything pretty easy but it does mean always having a connection when you want to develop. Not that exporting and then importing is any hardship.

I'd much rather have the database manage the keys in any case (multiple front-ends to your database) so looking forward to the next release.

- david

[Jan Aleman]

unfortunately although bob's posting is correct that you can set autoenters on database level this will not solve your problem.
It's impossible to get the primary key after inserting it as you don't know what its value is. There is a solution for databases like postgresql and oracle that support sequences (you could get the sequence right before the insert) but not for sequences ON columns currently. The only possibility is to write custom code for each existing SQL backend as most do have some custom functions to be able to handle this, that functionality is currently being investigated but will not make it into 1.1 for which the feature set has already been frozen and is in final testing at the moment.