>>>Yep, sure is, but I have had wireless connections that wouldn't work , even with TS. A basic scan found heaps of spectrum interference.
>>
>>But then nothing would work on such networks, right? And TS has a timeout. If you get disconnected, it waits (20 min or thereabouts is the last default I remember) and doesn't close your app before it times out in case you reconnect.
>>
>>OTOH, you're right, I don't see why we'd have to write workarounds for hardware problems. I've seen even wired networks which were unreliable - welding, X-ray machines and few other sources operating in the vicinity of network cables can really ruin your connection. Or fry the NICs, as it happened sometimes.
>
>That is why client server is so important in marginal connectivity situations.
>
>You won't corrupt a SQL Server database because you had a bad network connection.

Exactly. Which most of the network apps should have done years ago - and whoever didn't, should do anyway (regardless of which server is it - we know Fox works just fine with any of them). The alternative, inventing a disconnected dbf operation, is just as much work, if not more, and will be powered by 1 HP (one horsepower), the guy who wrote it. Makes no sense to do that. Even running an app on MSDE or 2005 Express is better than trying to deal with dbfs which just close on you.