I have several users who swear that every couple of months or so they save a record and then when they go back to work on it it's not there. I have not been able to get them to let me know about it before they recreate the record, although I just let them know if they want help they must do exactly that. I would put it down to 'forgot to save' except it's the same table every time and these users are generally exceptionally detail oriented conscientious etc.

Clients and Server are W2K, they should be service packed (server is SP4). We are running Arev 3.12 with the NT Service, write behind caching is disabled (server has a Raid array and write behind caching is greyed out in the options window via device manager).

Has anyone seen anything like this and have any suggestions? My first thoughts are to search on an indexed then unindexed field for the missing record, compare counts via select/count, check for MVID's. Any I'm missing?

Thanks in advance,

David Craig.

David,

The last time a client reported something like this we were convinced it was user related. However, the client was convinced otherwise. Therefore, we agreed to develop an MFS that would monitor the writes and deletes and create an audit trail. If we could prove that this was user related then the client would pay for our work. Otherwise, we would eat it and also put in the time necessary to fix the problem.

Suffice to say it was rewarding having the client pay for a utility that we now provide as a value-added-service to our other applications. This doesn't mean that it is impossible for something seriously wrong to be happening, but if your NT Service configuration is solid then I am skeptical that records are just disappearing on their own.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

And WBC is disabled on the workstations?

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

An idea that comes to mind is that this could happen if not all users are connecting to the file in the same way. In other words, one is going through the NT service or NLM and another is not. If this is the cause of the problem, though, I'd also expect to see GFEs cropping up.

I had this problem once and it turned out to be a code bug.

We had a pre-save process on a particular window that was making related updates to other tables. Very occassionally, the process would stomp on @ID and set it to null or some other value.

Our main record was then getting written to the table with a key value other than what we were expecting.

That took quite a while to track down, as I recall. I believe that's one of the times that I really learned the difference between "pass by reference" and "pass by value". *grin*

msorrel@greyhound.com

Greyhound Lines, Inc.

Thanks everybody for replying. I'll look at the code - we have some large complex programs driving our forms so it may be something like what Matt found. A blank id would definitely do it - we have occasional MV ids crop up but those are obvious since all of a sudden the users are finding nothing at all.

We only access the database in house and Novell is a faint memory around here these days, so that is probably not it.

If we don't come up with something the next time it comes up I can look at Don's solution, I believe the users but we can fool even ourselves sometimes.

Sprezz I have to admit to not having the foggiest idea what WBC is, Web Based Communities? World Boxing Council? World Barista Championship?

Thanks again;

David Craig.

Whoops - Write Behind Caching…. sorry

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

1) Sorry if this will be send trice :(

2) We had observed simillar problems in one of our main tables, I had added MFS to check write and deletes and found no problem.

3) I checked the .ov file and found two missing records in non used chains.

4) When I am RLISTing the table, regularly a record with empty key is listed (even when I delete it using RBasic, it reappears with contents corresponding to an existing row with a "randomly" choosen key).

5) Noone reports missing row for a long time.

2)… may be users were deleting the records before MFS was instaled,

3)… I don't know how the unused frames of the OV file were created, but the rows can be here from the time before they were correctly deleted. Any comments?

4)… It may be problem described by you Matt … I should check it, but it does not delete records, it just does not create what you expect … surely good point how these records with empty key are created.

View this thread on the forum...