wysiwyg database repair

well... i have an following idea:

I think many people here are using digital data gathering in some particular implementation ... it can be cheap or solid, battery backup error-proof solution ... but sometimes you still need to perform service intervention which will surely corrupt data in some way ... for example on following temperature trend are many blank spaces (in the middle) visible on every curve and three vertical lines ... this is an temperature trend from pc-based recording system ... lines indicate restarts of the machine and spaces indicate that termoclouple disconnection which i was forced to perform manually on analog unit ...

http://www.alteruter.net/temp/plcs.net/cx/cx_blank_data_spaces.jpg

I don't like these corrupts. Customers don't like corrupts in their nice graphical trends. But there is no way to avoid them.

What i have in mind ... is (quite simple) program with graphical interface, which will allow you to fill missing spaces using mouse to draw it directly into graphical trend.

I can surely handle that. At least, until somebody knows about something already existing.

Would be anybody interested in win32 tool for this purpose?
(if i will make it - it will be freeware solution)
Database format i'm using is always typical dbf/odbc where one column mean one curve and every record is signed with date and time of various period. Values can be int/float signed/unsigned. Here's lookup of file:

http://www.alteruter.net/temp/plcs.net/cx/db_data_lookup.jpg

I myself prefer simple DBF3/4 files, where every day is saved as single file, named as particular file mask including date ... like "klm1 (20050825 0000).dbf" - it's just years long custom and allows me easy data use in many applications.

Bad Idea!

What your asking for is absolutely absurd! What you're saying is you'd rather provide inaccurate data than no data at all. Very poor choice.


Greg

Why bother actually collecting information at all ? And wasting the money on a database? A piece of graph paper and a crayon can provide perfect, if inaccurate trends of any process data.

That's one problem, the second, should you decide to continue anyway, is that while YOU may prefer a DB3/4 file, some people use Access, or SQL, or Oracle, some people use a historian running on top of the above, with complicated referential checks. How do you propose to deal with a nearly infinate variety of formats?

rdrast: well... ODBC, so format itself is not problem at all... the variety of formats was what made me ask here... database is easy to be shared on network, for excel/word/graphical exports and prints of any resolution etc.

greg: i was simply talking to company fellow who encountered in problem with very unpleasant customer and thought this would be the solution... but i really didn't considered it from "your sight"... you finally cooled my enthusiasm

...it really looks more like stupid potemkin, thanks for opinions

Any regulatory agencies would frown upon this concept. Possibly even fine the customer and you.