[Pete_Keller (OP)]

[quote="

[SteveAlt]

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

[Pete_Keller (OP)]

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

[Þórgrímr]

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,

[Pete_Keller (OP)]

Erik,

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

Thanks
Pete

[SteveAlt]

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

[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...

[Pete_Keller (OP)]

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.

[Pete_Keller (OP)]

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

[Steve Walmsley]

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

[Pete_Keller (OP)]

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

[Erik L]

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 Walmsley]

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

[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...

[Þórgrímr]

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,