Tim

Would you be so kind as to create a small set of corrupted tables and make them available for download. The rational is that its very difficult to test error handling when you don't have an error, and probably never will have.


Roy Lambert

Roy Lambert wrote:

> Would you be so kind as to create a small set of corrupted tables and
> make them available for download. The rational is that its very
> difficult to test error handling when you don't have an error, and
> probably never will have.

The problem with this is that the corrupted tables won't reflect
anything useful for anyone. What is the point of opening a table with
invoice data in your GPS logging application? I suggest that a more
useful facility would be to be able to generate specific exceptions on
demand. You'd enter a special debug mode, and then make a call to
request a certain exception. Then on the next call, it would generate
that exception and your code would be tested for the proper reaction.

But I'm trying to work out why I can't actually generate that in my own
code anyway, with a bit of clever ifdef use just before the call into
the database. Given that, why pollute EDB with test code?

Of course I may be wrong in how I'm thinking on this, but then I think
it would be better for Tim to give us a clue on how to hex-edit the
files. Perhaps there are markers that we can look for, and edit them to
make it invalid?

--

Matthew Jones

Matthew

>The problem with this is that the corrupted tables won't reflect
>anything useful for anyone.

Correct but it would allow testing of error handling

>What is the point of opening a table with
>invoice data in your GPS logging application?

None so I wouldn't do it

If you want it relevant what about the CD collector example

>I suggest that a more
>useful facility would be to be able to generate specific exceptions on
>demand. You'd enter a special debug mode, and then make a call to
>request a certain exception. Then on the next call, it would generate
>that exception and your code would be tested for the proper reaction.

No, never etc

The very thought of the general public being able to create corruption at will fills me with horror.  Its bad enough they can do things via Windows but having a dedicated tool - shudder

>But I'm trying to work out why I can't actually generate that in my own
>code anyway, with a bit of clever ifdef use just before the call into
>the database. Given that, why pollute EDB with test code?

You probably could if you knew what you were doing.

>Of course I may be wrong in how I'm thinking on this, but then I think
>it would be better for Tim to give us a clue on how to hex-edit the
>files. Perhaps there are markers that we can look for, and edit them to
>make it invalid?

See comment above re No, Never etc


Roy

Roy Lambert wrote:

> If you want it relevant what about the CD collector example

How does that help me test my invoice code?

> No, never

Yep, which is why it isn't a sensible option. Info on how to corrupt
perhaps, but do you really want the info out there on how to break your
applications? (Sure, security by obscurity, but hmmm).

--

Matthew Jones

Matthew

>> If you want it relevant what about the CD collector example
>
>How does that help me test my invoice code?

It helps you build tested code that can then be ported. I agree it would not be tested on your specific data but if you black box it properly it doesn't need to be.

>> No, never
>
>Yep, which is why it isn't a sensible option. Info on how to corrupt
>perhaps, but do you really want the info out there on how to break your
>applications? (Sure, security by obscurity, but hmmm).

Which is why I'd like pre-corrupted tables not the method of how to do so.

Roy

Why not just copy a table file, open it in a hex editor, and change some
random bytes?  That would certainly corrupt it!

--
David Cornelius
Cornelius Concepts

David


That would probably end up only corrupting the data. ElevateDB doesn't care if the surname column for someone has Cornelius or £$(^%$"

Roy Lambert

On 4/19/2015 4:22 AM, Roy Lambert wrote:
> Would you be so kind as to create a small set of corrupted tables and make them available for download. The rational is that its very difficult to test error handling when you don't have an error, and probably never will have.

I second this one - would be very useful to have a set of corrupt tables
that represent various error conditions (both recoverable and not).

We're just going thru a quality management program and DBISAM for us is
SOUP (Software of Unknown Provenance) so we actually need to prove the
risk factors when using it and this would go a long way.

Raul