Random data changes VFP database on W2000 server

[mikeopolo]

Hi, a client is experiencing what appear to be random data changes to stored data, even after going through their entire data table manually and saving every change.

The particular field is custom-labelled, but the underlying name doesn't change.

Can anyone offer pointers as to why this might be happening and what to do about it?

 

[Mike Lewis]

Mike,

As I'm sure you'd agree, this can't really be a "random" change. There must be something in your application, environment, hardware or elsewhere in the system that is causing it. It's impossible for anyone here to know what that might be.

Also, in order for us to help, you'll have to clarify your question. In particular:

- What is exactly happening when the data "changes".

- What do you mean by "going through the data manually and saving every change"?

- What do you mean by "custom-labelled"?

If you could be more precise in your question, we might be able to help.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[mikeopolo]

Thanks Mike

You've made some good points, I was unsure what to say.

The text field holds a certain value for each employee. After adding or changing the value using the employee edit screen in the application, and saving each one (as opposed to editing several records and saving at the end as the app permits), the data appears to be correct.

At a later time, maybe only a day or less, the contents of the fields have changed without being edited, typically where a particular value now appears in a number of subsequent records, in place of the value edited to those records.

I've not seen this behaviour before in a VFP app, but I have in an Access database which was running on W2000 without the latest patches. So I am having that checked.

The point about the custom label is a red herring I think; it just happens that this field is a user-defined field, whose label/title the user can change.

Regards
Mike

 

[Mike Lewis]

Mike,

OK, that's much clearer. You've explained the nature of the problem, but from this distance it's hard to know what could be causing it.

Can I just check one point: When you see this changed data, are the new values really new? Or is it the case that the values are reverting back to what they were before the users did their edits? If the former, are they sensible values, or just rubbish?

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[mikeopolo]

The values are not 'rubbish' values - as I said, typically the correct values are being replaced by another valid value across the next say 10 records.

 

[Imaginecorp]

Are there any Stored Procedures in the database that might be changing the values?
Any thing in the Valid() of controls in forms?
Cannot be Default Values as the fields are not empty.
IMO the above is the only way to change existing values...

 

[mikeopolo]

Thanks, I would need to refer this to the application developer for their comments, will advise.

 

[Mike Lewis]

Mike,

I would need to refer this to the application developer for their comments,

Ah, so you're not the developer? That throws a new light on it.

Whatever is causing this problem, it's quite likely to be a fault in the application itself. It's really up to the developer to track it down. The best thing you could do is to give the developer as much information as possible, and have him / her find what's causing it.

If appropriate, the developer can come into this forum, and ask for help on any specific VFP-related technical issues.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Auguy]

This won't help if you have coding issues. We had a similar situation several years ago and ended up totally rebuilding the table and the indexes. By this I mean physically creating a new table and index and then replacing the old versions. Probably won't help, but you might discover some sort of pattern or irregularities when rebuilding the data that may help in tracking down any coding problems. Don't forget hardware (nic cards, cables, etc) but these problems generally corrupt the tables not just change random fields. Another thought, is is possible that row buffering is turned on and the user is changing this field and then moving the pointer to another record and committing the change?

Auguy
Sylvania, Ohio

 

[mikeopolo]

Thank you; I am not developing this payroll app but I am writing reports with a VFP report writer against it. I should have said so in the beginning.

The users were in the habit of editing several records then commiting the changes, and we thought that might be the cause. But now they are editing and saving one by one, and the problem still exists.

Just another angle - the employee table was populated with data from another payroll system, by the developers for us. I don't think this should affect it, but we can only ask.

 

[SBTBILL]

Do you know what kind of tables you are using? SQL treats UPDSATE without parameters as update all. I would reindex. I've very rarely seen this type of behavior with a corupted index.

Bill Couture
http:\\

http://www.sbtbill.com