We have spent two weeks working on a new solution. The developer made no backups of the servoy folder (grrrrr.)
The machine - a G4 Mac Mini, slipped off the pc it was standing on and unplugged its power while servoy was running…
I have never ever lost so much as a single character in Servoy before (and I do back up almost every time I use Servoy), but it seems really to not like having been turned off this time… When we try to restart servoy, we get “Can’t connect to repository server specified in application preferences.”…
Sybase is not starting up at all.
Following the database recovery instructions here: http://forum.servoy.com/viewtopic.php?t=2897, I try a recovery. The response in my terminal is: Last checkpoint at Wed Apr 25 2007 10:25
Checkpoint log…
*** ERROR *** Assertion failed: 201129 (9.0.2.3045)
File is shorter than expected
Abort trap
bevil-templeton-smiths-computer:~/Desktop/Servoy_3.0_installed/sybase_db thunder$
The Sybase log says something along the same lines: “I. 04/26 11:53:19. Running on Darwin 8.9.1 Darwin Kernel Version 8.9.1: Thu Feb 22 20:55:00 PST 2007; root:xnu-792.18.15~1/RELEASE_I386 Power Mac
E. 04/26 11:53:21. *** ERROR *** Assertion failed: 201129 (9.0.2.3045)
E. 04/26 11:53:21. File is shorter than expected”
I know it is our fault for dropping the machine and not having any backup (Grrrrrrrr…) but does anyone have any ideas on anything we can do to retrieve the repository… We will lose 2 weeks of work if we cannot get it running again…
I believe you can rebuild the database by reapplying the log file.
Harjo (HJK) could explain it better to you since he has done this twice already.
Or else check the manual(s).
I wish it was that… I have moved the servoy folder to my own developer machine and I have the same problem. I think that the servoy repository db is definitely corrupt…
Any guidance on how to recover using the log file would be appreciated…
No, I think it is really, truly and completely corrupt. I’m keen though to find out how to remake the repository db out of the repository log though, if anyone can point me at a forum thread, or knows anywhere I can read up on these things, I’d be grateful… Otherwise, the developer must do the work again.
Hey everyone, thanks for the supportive suggestions…
For anyone needing to do this in the future, the info about this is very sparse and I didn’t find the following solution in any one place… No doubt someone will now show me the forum thread where it is all neatly laid out… Anyway, to fix, you need to do the following:
Using Sybase Central > Tools > Adaptive Server Anywhere > Translate Log File…
This creates an sql file from your log file. This is (by all accounts) a string of sql commands that were used in the initial building of your servoy_repository (in my case it was servoy_repository but it would hold for any .db file). The file will be saved to your filesystem as yourdatabasefilename.sql (in my case servoy_repository.sql)
Still in Sybase Central, Create a new empty sybase database called servoy_repository (or whatever your .db file is), I unloaded it (Sybase Central > Tools > Adaptive Server Anywhere > Unload database). This .db file will become the recovered database
in InteractiveSQL, connect to your new database and issue the command: ‘read /your/path/to/your/database.sql’
That should do it… Mine took 30 minutes to build a 16MB servoy_repository.db file out of an 80MB servoy_repository.sql file.
Replace your faulty database file with the reconstructed one and you’re away…
I remember you saying in a reply to one of my questions years ago that you save your transaction logs because of belt and braces instinct… Good call, I have discovered…
The error “*** ERROR *** Assertion failed: 201129 (9.0.2.3045) File is shorter than expected” happened to me too. I solved doing this:
“db” file certainly was corrupted. But I had “log” file ok, I used “dbtran” to translate the actual log.
I had a previous backup of 05/2010 and then I translated the old log too.
I compared the two logs (actual and old) with “UltraEdit” (the only app that made it successfully, the log file translated had 7GB) and found the point where the two logs started to be different.
I deleted from actual log the sql commands that old log already had.
I started the backup of 05/2010 and executed the SQL remained of step 4.