Does anyone know a quick and easy way of corrupting a database table? I would like to do so for testing purposes - catching any error when attempting to open the corrupted table and then handling it based on client requirements.

Thanks!

Aaron


I remember asking Tim this once. Without searching I think the answer was set a breakpoint in ElevateDB source  and just bomb the program. I'm going to add a suggestion that Tim makes available some corrupted tables for testing - feel free to upvote.

You could also get a hex editor and try changing chunks of the data at random. If you're looking for corruption in the header hack the top of the file otherwise somewhere in the body. Its not guaranteed but it might work.

Probably the best way is to give the program to a user - generally works for me

Roy Lambert

I could just edit the table in an editor and remove some characters yeah?

The main error I seem to see is #601 and just found another:

exception message : ElevateDB Error #100 There is an error in the metadata for the table settings (A write operation did not complete and a repair is required).

I would like the actual errors but as yet we do not have access to them. The next iteration allows the user to upload the database to the server at the click of a button so I can get access to them and see what's going on, however I am pretty confident a verify +/- repair will sort 99% of the app issues we have that require reinstalls.

Thanks for the response.


I guess the reason I want to have this specific error triggered (ie legitimately) is so I can look at it in the debugger and see it in the flesh and write code to handle it more gracefully. At the moment we are doing reinstalls (app is used around the world so timezone issues are the biggest problem here). Rather than doing a reinstall, a DB repair will probably sort out most issues with only the occasional reinstall required.

Aaron,

When I get this urge to deliberately corrupt tables, I just keep jabbing myself in the eye with a sharp stick until the urge goes away.

As a test, you need to think like a user.

Simply delete the index file for a table, or delete the blob file and see how your application handles it.

Or have the application point to the wrong data directory or to directory that does not have the configuration file in it.

Or restore a couple of tables from the backup after its config file was modified for these tables.

Barry

Barry wrote:

> As a test, you need to think like a user.

Or open the file in Word, and then save it.

--

Matthew Jones

Barry

>When I get this urge to deliberately corrupt tables, I just keep jabbing myself in the eye with a sharp stick until the urge goes away.

Next time ask for assistance - you seem to be missing the organ

>As a test, you need to think like a user.

Just tried these in EDBManager to confirm my suspicions. Tim may be handling this stuff within EDBManager or it might be built in to ElevateDB which is what I suspect

>Simply delete the index file for a table, or delete the blob file and see how your application handles it.

ElevateDB recreates and empty index file so it seems as if you have an empty table - REPAIR TABLE fixes it

ElevateDB recreates an empty blob file - you're lost anything that might have been in there

Both of the above very difficult to test for - I don't bother (because I can't think of a sensible way to do it) and leave it up to the user to decide to run the repair option I have built in.

>Or have the application point to the wrong data directory or to directory that does not have the configuration file in it.

I like this one - easy to catch and do something about

>Or restore a couple of tables from the backup after its config file was modified for these tables.

This will probably (certainly in the early days of ElevateDB)  generate a metadata error, but might not depending on just what was altered.

Why I'd like some corrupted tables to play with is that whilst I can built in what I think is good error handling its essentially untested code. I don't like untested code.

Roy

Matthew

>Or open the file in Word, and then save it.

I've never tried that - what happens?

Roy

Roy Lambert wrote:

> > Or open the file in Word, and then save it.
>
> I've never tried that - what happens?

I've never tried it with Elevate files, but it is a pretty good way of
mangling files as it saves it back in Word format. Why users ever think
it is a good idea I don't know, but I've seen it done.

--

Matthew Jones

This is the error I want to catch:


Exception: ElevateDB Error #601 The table <table name> is corrupt (The index __PrimaryKey contains duplicate keys).