Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Now and then wrong data is inserted in oracle

Re: Now and then wrong data is inserted in oracle

From: Jeffrey <jeffreybultinck_at_hotmail.com>
Date: 3 Dec 2004 03:58:48 -0800
Message-ID: <6eca5fca.0412030358.743719ef@posting.google.com>


BigBoote66_at_hotmail.com (Steve B) wrote in message news:<67bcf80a.0412020824.61bec90c_at_posting.google.com>...
> An example would go a long way towards allowing people here to figure
> out what's wrong. However, lacking that, here are my thoughts:
>
> You say the data is "wrong". How wrong, exactly? Are some of the
> rows resulting from the operation in error, or does the whole thing
> seem fouled up?
>
> It is unlikely that it is an Oracle or ODBC problem. My guess would
> be that
>
> 1. You have a race condition in your file retrieval code.
> 2. You have some unitialized data that is being re-used in subsequent
> scans
>
> If bad data is manifesting itself as completely messed up results, or
> as incomplete results, I would guess it would be #1. The most common
> problem in this kind of application (where a client app waits for a
> file to appear, then processes & sends it), is that you app is picking
> up the file before it is completely written out. If you are scanning
> a directory and waiting for the file to appear, you can easily run
> into this problem. Typically, the way we've gotten around this
> problem is to have the file-dropping process copy the file to a
> staging directory on the same disk, then once the copy is done, use
> "mv" (if using unix) or "move" (if using windows) to put the file into
> the scanned directory. The other way is to have the file-dropping
> program drop a second "terminal" file that the scanning program
> detects, and once it detects it, it looks for the corresponding real
> file (For example, after dropping file foo.txt, you drop a file called
> DONE_foo.txt, which your scanner would interpret to mean "now process
> file foo.txt").
>
> If your bad data just shows a limited number of screwed up items, it's
> probably because your scanning app is re-using global variables from a
> previous file and not re-initializing them. Since Visual Basic
> automatically sets all variables to some initial value (such as 0 or
> ""), it is easy to forget to initialize them. But if you are using
> global (or module-level) variables as scratch space, you may be
> polluting your data in subsequent runs. Make sure that you're
> initializing all non-local variables that you use before processing a
> file. This all assumes that your scanning app runs continuously and
> may process many files in its lifetime; if you are running the file
> processor fresh for every file, it is less likely that this is a
> problem.
>
> -BbT
 

It was indeed a global variable in our VB program that wasn't initialized. Unbelievable I missed that. Normally I only use local variables just to prefent this kind of errors. As we took over this program, it is hard to find such kind of bugs.
Anyway thanks for your input to solve this problem. Received on Fri Dec 03 2004 - 05:58:48 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US