Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
TableUpdate()
Message
General information
Forum:
Visual FoxPro
Category:
Other
Title:
Miscellaneous
Thread ID:
00716150
Message ID:
00716664
Views:
17
>George,
>
>>>>>>>I have a Client/Server application with remote views against tables in a MS SQL 2000 database. Occasionally, even though TableUpdate() returns .T., the SQL data is not updated. I've confirmed that the correct field value is present before the update is issued.
>>>>>
>>>>>George,
>>>>>
>>>>>Yes, "Send Updates" is checked. Remember it only happens (fails to update)occassionally. I'm beginning to wonder is it's an issue with the machine's local cache, or the ODBC driver, or a SQL 2000 issue.
>>>>>
>>>>Joe,
>>>>
>>>>One other thing to consider. SQL Server (all versions) depend on there being no write behind caching. IOW, if the server is set-up to allow write behind, that may be the source if your problem. Inside SQL Server 7.0 documents this. What I'm guessing may be occurring is that between the TABLEUPDATE() and REQUERY() the updates haven't been committed to the disk.
>>>
>>>George,
>>>
>>>write behind caching was enabled. We are disabling. Thanks.
>>>
>>Joe,
>>
>>Great! You may pay a small penalty with updates and inserts, but it's well worth it. The previously mentioned book is very emphatic on the point that the controller mustn't report that the "bits have hit the disk"< s >, until they actually do.
>
>What you say is absolutely what I remember too BUT the whole issue (in the book) related to a sudden system loss, as in a power failure.

This is true, and to take it further, it mentioned that write behind cacheing was only acceptable in those situations where the controller itself had a battery backup.

It may well that write behind cacheing on the server isn't the problem. However, at least it will now be eliminated as a possibility.

>Now this situation doesn't mention a power failure. Nor does JoeM mention the OS involved.
>But along the same lines, but confined to Win2K I believe, is some bug that fails to write cached stuff, even on an orderly shutdown. And until SP3 for Win2K, turning off the write caching for a drive only worked within the current boot and it would be reset to enabled again upon a re-boot.
>
>So if the OS is Win2K then SP3 is probably a good idea too.

I don't think that the client side OS enters into the equation simply because the data is being sent to the server. It is always a good idea to have the lateast SP applied, though. On the server side, however, SQL Server manages the use of the file system without much, if any assistance from the OS itself.
George

Ubi caritas et amor, deus ibi est
Previous
Reply
Map
View

Click here to load this message in the networking platform