Hi, apparently I broke it. Sorry for that.
In version 1.3.148 Thomas did refactor it, so I guess you might have another result with a newer version. Please try it and tell me if it works for you. I will then make a 1. 2 version with the fix for you (though I'm very busy at the moment, so it could take some time). Regards Christian On Feb 14, 6:12 pm, SuperSpinner <[email protected]> wrote: > Sorry for taking so long to reply here. I did a little debugging, and > I see 2 reasons why the upgrade doesn't happen (I haven't looked at > the 1.3.148 source code which may have fixed all this). > > First, the first time Driver.connect() decides to call > DbUpgrade.upgrade(), it passes in the url that it got from the jdbc > url. this is used to check a static Map called runningConversions to > see if it has been added as a key. > The first time it hasn't, so the url is added as a key and the > "instance" is used as the value. Then DbUpgradeFromVersion1.upgrade() > is called. > > In DbUpgradeFromVersion1.upgrade(), after "script to" has run, > DbUpgradeFromVersion1.upgrade() again calls > DriverManager.getConnection() to get a connection in order to run > "runscript from" and by way of Driver.connect() finds itself again in > DbUpgrade.upgrade() with a passed in url. It checks this url with the > runningConversions map but doesn't find it and again calls > DbUpgradeFromVersion1.upgrade(). > > This is wrong. It should have found that it was already migrating and > just returned. The reason for the incorrect behavior is that the url > passed in the second time is like the first url but has > unwanted properties stripped from it and then some extra properties > added ";UNDO_LOG=0;LOG=0;LOCK_MODE=0;", so this code would never have > worked unless the original url had ";UNDO_LOG=0;LOG=0;LOCK_MODE=0;" at > the end with none of the other properties that are stripped out. I > fixed this. but..... > > Second, Once I fixed this I discovered that the code that renames the > dbname.data.db and dbname.index.db files to dbname.data.db.backup, > dbname.index.backup was failing (this is on windows and it said the > files were in use) so when that second getConnection() ran expecting > to not find an existing database and create a new 1.2 database, > instead finds the old database, tries to read it and errors out saying > the file header is wrong. > Two problems here, first obviously no check is made of the return > value of the renames to see if they succeeded, and secondly, why is > the file considered still in use? > > Need to figure out why the 1.1 database files are still in use. the > connection was closed. I even tried unloading the old 1.1 driver but > that didn't work (this is in DbUpgradeFromVersion1.upgrade()). > > ??? > > On Feb 5, 2:57 am, Thomas Mueller <[email protected]> > wrote: > > > > > > > > > Hi, > > > Could you post the complete stack trace including all 'root cause' > > traces? Could you also describe exactly what you do so that we can > > reproduce it? > > > The upgrade does rename the directory, but _after_ creating the > > script. So the directory shouldn't be needed afterwards. > > > Regards, > > Thomas -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
