I use SQLDiff at work, you can run two different comparisons. One on the actual data stored in each table and then one on the structure of each table. It will then provide you with the SQL so you can run it yourself or you can just click on and let it do the changes for you.

Pretty sure there is a 30 day trail and then after that you need to pay - but it helps us alot at work especially atm since in the last two weeks I have created about 10new tables and views and will be editing stored procs. This just takes the hastle away

http://www.apexsql.com/sql_tools_diff.a ... DAodBSaMQQ

Speaking of automated processes, I just found this:

http://access-data-transfer-assistant-2 ... picks.com/

It claims to be a way of distributing .mdb updates.

You can easily tell VB to update its version everytime you compile (or leave it as a manual process). The problem is, this won't prevent you from forgetting to update the values in the MDB. This part can't be automated in the VB6 compile process...

Quote from: "Steve Walmsley"

Quote from: "Pete_Keller"

Steve could you add another table to 2.4.

Call it "Aurora_Version"

with fields called "Major", "Minor", "Revision", "Subrevision"

and currently set to 2, 4, 0, 0

This will allow you to check if the program is using the correct database.

It will also let me or someone else writing a conversion script to know which version of Aurora is in use.

Pete

I have added a three field table with major, minor and revision but there are a couple of problems with this approach.

a) An increment to minor indicates a database upgrade while revision indicates a code update. Therefore, even if I updated the database with the revision number, that would be no use to you because the databsase wouldn't be part of the upgrade. Really all you need for the database version though is the major/minor fields

Steve

As someone who is not that familiar with VB6, but is familiar with make and ant, is there a scripting capability in the method of creating the exe file?

Pete[/quote]

Actually if Steve is using app.majorversion & app.minorversion, they'll update automatically. However, updating the database... I'm not sure.

Steve could you add another table to 2.4.

Call it "Aurora_Version"

with fields called "Major", "Minor", "Revision", "Subrevision"

and currently set to 2, 4, 0, 0

This will allow you to check if the program is using the correct database.

It will also let me or someone else writing a conversion script to know which version of Aurora is in use.

Pete

I have added a three field table with major, minor and revision but there are a couple of problems with this approach.

a) An increment to minor indicates a database upgrade while revision indicates a code update. Therefore, even if I updated the database with the revision number, that would be no use to you because the databsase wouldn't be part of the upgrade. Really all you need for the database version though is the major/minor fields

b) This relies on me to remember to update the table. Given my record updating the about box and copyright window, that is by no means guaranteed

Steve

Unless Steve has ahd a significant change of database design, it is extremely difficult to correctly do an upgrade simply due to alll the auto numbers assigned and used as keys.

Any upgrader script needs to account for this problem...

Yes, I am looking into it.

Erik,

can you split the xml discussion off of this topic and stick it in mechanics or something.

Thanks
Pete

Probably installation would be the best sub-forum for this.

Steve

Pete's right, the big thing is the star systems. For example, the Campania System in the previous version was a trinary system, what is what I needed so I did not have to create and delete multiple systems to get one. I do not expect to be so lucky this time.  




Cheers,