Long shot - Losing records by 4s

[CALocklin]

This is a long shot but I thought I'd ask anyway.

I have one application that seems to be blanking out records periodically. They always 'disappear' in consecutive records in multiples of 4 - 4, 8, or 12 is all I've seen so far. This should even be able to happen because many of the fields are set as Required fields!? It generally happens only once every month to 3 months but it's creating major concerns because these are customer orders that are disappearing.

The other strange thing is that all fields are blanked out except the 4-5 logical fields - which all default to .F. but end up as .T. when everything else is blanked out.

I suspect it's either something in my code or it has to do with their occasional network problems but we haven't been able to pinpoint when this is happening. The only thing we are fairly certain of is that they disappear on the same day they are entered. We are fairly certain of this because the orders don't seem to get printed at the end of the day.

One other thing is that some of these groups of blank records may be created by the system rather than being the result of blanking out existing records. I'm able to give them a range of missing work orders and sometimes the range doesn't exist. (They mark each original order, which is on paper, with the work order number generated by the application and keep them in order by date - which is generally the same as the work order sequence.) They workers don't notice the skipped range of numbers because there are 4 people entering data.

Any thoughts??

[CALocklin]

RE: Long shot - Losing records by 4s

Correction:

I have one application that seems to be blanking out records periodically. They always 'disappear' in consecutive records in multiples of 4 - 4, 8, or 12 is all I've seen so far. This shouldn't even be able to happen because many of the fields are set as Required fields!? It generally happens only once every month to 3 months but it's creating major concerns because these are customer orders that are disappearing.

[Stan Mathews]

RE: Long shot - Losing records by 4s

Four records at a time? Really strange.

About the only thing that makes any sense, if a wild guess could make sense, is the relationship between

"4 people entering data" and "'disappear' in consecutive records in multiples of 4". Would seem likely that some process is colliding with another and the app winds up either not completing a set of saves.... or makes an unintended turn in a script and "some of these groups of blank records may be created by the system".

If you are finding sets of four blank records whose order numbers were not recorded by the data entry personnel, doesn't that mean that the save record script (?) fired for each station in a cascade fashion?

I know this is probably not new information for you and doesn't offer any solution.

[JerryBrightbill]

RE: Long shot - Losing records by 4s

Cal

Stan makes an interesting point. One of the keys to any troubleshooting is to look for commonalities. Are the lost records entered by the same person? Does it happen at the same time of day? Are they from the same computer? Is anything else happening at the same time, like a scheduled automatic virus scan?

You may want to add a couple fields for testing and save the time and date when a record is saved as well as the computer name and maybe user name. Perhaps you could output that info to a text file on the CanSave and again on the OnSave. Later, you could check the "missing" records against the text files.

Another check would be to tally the number of records at the end of each day. This would show which day the "lost" records occur if the day total doesn't match the previous day + records added.

I once found a weird error message problem by trapping a rolling record of the last 20 key strokes and actions that were automatically output to a text file when the error was trapped. I found that the user was hitting save multiple times before code on the CanSave and Onsave were complete. Of course, they denied it.

Jerry

[Peter.Greulich]

RE: Long shot - Losing records by 4s

Cal,

In addition to Jerry's suggestion. Yoou might try employing Alpha's "built-in" audit trail feature for deletes and for changes.

PG

[Peter.Greulich]

RE: Long shot - Losing records by 4s

Also: Can you wite the records to a 2nd generic tble as they are being entered?

[JohnZaleski]

RE: Long shot - Losing records by 4s

Are you sure that orders are being properly saved and then blanked out at a later time? What evidence makes you sure of that?

[CALocklin]

RE: Long shot - Losing records by 4s

John, I'm not sure whether they are properly saved or not.

Everyone,

A lot of good ideas here - thanks. I already am putting the user info in the table but it doesn't do any good in this case because the record is blanked! The times are random based on the surrounding records and there is currently no way to tell who created the blanked out record originally. However, I've obviously missed the forest for the trees because I hadn't considered saving the user name, etc. to a text file - duh! I'll try that or the audit trail and see what I can find out.

By the way, I did create a routine to test for blank records. They were supposed to run it at the end of every day before printing work orders and whenever anything suspicious happened. Guess what didn't happen!

[csda1]

RE: Long shot - Losing records by 4s

Hi Cal,

What is the record length in the database? Is it, by any chance a divisor that goes evenly into 512 bytes (1 sector size) or your cluster size of the hard drive?

If it is, then you may be having bad writes. Try turning on write verify on your server and see if the problem goes away (You'll lose about 5% disk performance). If it does, it's your server. If not, then the other thing to look for is null's (Ascii 0's) in the table data where the blank records are. This could also be a source of the problem. Get a hex dumper (I use HexMad) and view the data and look for funny characters in the area.

Look at the table using the default form, and see if the 1st or last fields of any of the blank records are truly blank.

Regards,

Ira

[CALocklin]

RE: Long shot - Losing records by 4s

Ira,

Record size it 805. I have no idea what the sector size is but will have their network guy let me know.

However, I feel stupid now for not thinking about looking at it with a hex editor. Based on your comment, I used a hex editor and found out that all bytes in the 'blank' records are hex 00 (not 20 [space] as for other blank record info) EXCEPT one field, Completed_byf, which is always hex 20 for all 30 characters. Even the first character of the record; used to identify normal, marked, or deleted records; is 00.

Based on this I checked every reference to the Completed_byf field (only 3 references) and the only thing I found which was at all unusual (although I don't see why it would cause this issue) was in the CanArrive event of one of the forms. (And, right now I can't tell you why it's in the CanArrive rather than the OnArrive - maybe there was a good reason, maybe not.)

The script in question was used to set the "default" value when closing out the work order. The "default" value is based on a global variable (g_comp_by). Unfortunately, it's not really a default value because it only gets entered after the job has been done and the work order is being closed out so the Default Value field rule isn't applicable.

Here's the original script:

DIM GLOBAL g_comp_by as c

IF this.value = "" .and. parentform.mode_get()="CHANGE" .and. g_comp_by ""
this.value = g_comp_by
END IF

END

The unusual part to me is that I used "this.value" since I seldom use that construction. I've rewritten it to:

DIM GLOBAL g_comp_by as c

IF parentform:completed_by.text = "" .and. parentform.mode_get()="CHANGE" .and. g_comp_by ""
parentform:completed_by.text = g_comp_by
END IF

END

I'm not at all convinced that this is the issue but at least it's something to check.

Anyone have any thoughts on these scripts or the zeros in the record?