Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB Enhancement Requests and Suggestions » View Thread |
Messages 1 to 8 of 8 total |
Corrupted tables for testing |
Sun, Apr 19 2015 4:22 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sun, Apr 19 2015 9:27 AM | Permanent Link |
Matthew Jones | 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 |
Sun, Apr 19 2015 11:36 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Mon, Apr 20 2015 4:00 AM | Permanent Link |
Matthew Jones | 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 |
Mon, Apr 20 2015 4:10 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Tue, Apr 28 2015 2:12 PM | Permanent Link |
David Cornelius Cornelius Concepts | 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 |
Wed, Apr 29 2015 3:09 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Wed, Apr 29 2015 9:16 AM | Permanent Link |
Raul Team Elevate | 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 |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |