Aurora 4x

VB6 Aurora => Installation => Topic started by: Pete_Keller on October 08, 2007, 12:46:02 PM

Title:
Post by: Pete_Keller on October 08, 2007, 12:46:02 PM
[quote="
Title:
Post by: SteveAlt on October 08, 2007, 12:53:41 PM
Quote from: "Pete_Keller"
It would be nice if Steve came up with a way of dumping and loading the starsystems to/from an XML file.

Then we could write an XSLT to update them to the new format, and keep the same star systems from revision to revision.

I have never used XML but anyone who wants to write an SAUpgrade type program is very welcome to try :)

Unless I change something to do with star systems, it should be possible to export and import them, although you will need to also move things like the game information because the system information will link to it.

System needs the Game table
Star needs Game and System (and Stellar Type but that shouldn't have changed)
SystemBody needs Star, System and Game

If you try moving race information and survey data though that is a lot more complex.

Steve
Title:
Post by: Pete_Keller on October 08, 2007, 01:02:02 PM
OK,

The main thing is for the database to have the same star systems from upgrade to upgrade so that the story can stay the same.

Pete
Title:
Post by: Þórgrímr on October 08, 2007, 01:20:09 PM
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.  :D




Cheers,
Title:
Post by: Pete_Keller on October 08, 2007, 02:42:05 PM
Erik,

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

Thanks
Pete
Title:
Post by: SteveAlt on October 08, 2007, 02:49:02 PM
Quote from: "Pete_Keller"
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
Title:
Post by: Randy on October 08, 2007, 10:23:48 PM
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...
Title:
Post by: Pete_Keller on October 12, 2007, 07:38:51 AM
Quote from: "Randy"
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.
Title:
Post by: Pete_Keller on October 12, 2007, 07:41:58 AM
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
Title:
Post by: Steve Walmsley on October 13, 2007, 07:45:09 AM
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

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
Title:
Post by: Pete_Keller on October 13, 2007, 08:40:14 AM
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[/quote]

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
Title:
Post by: Erik L on October 13, 2007, 08:57:51 AM
Quote from: "Pete_Keller"
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.
Title:
Post by: Steve Walmsley on October 13, 2007, 09:03:20 AM
Quote from: "Pete_Keller"
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?

VB is like programming for the under-fives :)

Incidently my commercial prgramming background (from many years ago) is in C and C++ but VB6 is so much easier to use for something like SA and much, much easier to hack around with later than C++ code

Steve
Title:
Post by: Randy on October 13, 2007, 02:15:41 PM
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... :-(
Title:
Post by: Þórgrímr on October 13, 2007, 02:19:27 PM
Quote from: "Randy"
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... :cry:  So we would have to rely on an automated process that would not require us to access the DB's.




 Cheers,
Title:
Post by: ShadoCat on June 25, 2008, 05:30:59 PM
Speaking of automated processes, I just found this:

http://access-data-transfer-assistant-2 ... picks.com/ (http://access-data-transfer-assistant-2003.custom-business-applications-corporation.alienpicks.com/)

It claims to be a way of distributing .mdb updates.
Title:
Post by: Erik L on June 25, 2008, 09:49:24 PM
Quote from: "ShadoCat"
Speaking of automated processes, I just found this:

http://access-data-transfer-assistant-2 ... picks.com/ (http://access-data-transfer-assistant-2003.custom-business-applications-corporation.alienpicks.com/)

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


The biggest issue is schemata changes. Without those, upgrading would be very simple. I'll send them an email and see if it handles them...
Title: Re: Aurora Upgrade Discussion
Post by: Beersatron on November 01, 2009, 06:37:41 PM
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 (http://www.apexsql.com/sql_tools_diff.asp?gclid=CN2R95SJ650CFSDxDAodBSaMQQ)