>>As I pointed out earlier on, without some additional costs on the server, you still have problems (for example, latency causing table corruption). If you're going to spend the necessary money to have the appropriate hardware (RAID drives, etc.) then the extra expense of SQL Server is worth the cost, simple you get things like the transaction log along with it.
>
>George, where I saw you write this kind of thing earlier, I can't see the point; you seem to say that with SQL-server (etc.) no Raid or additional backup-facilities are needed ? because SQL-server can do a roll-forward in case of hardware-failure ?

No I'm not advocating that. The SQL Server guidelines are very specific as to the type of hardware involved, and specifically mentions the need for backups and UPSes, as well as disk controllers that accurately report when the bits are on the disk, as well as RAID drives. All of this is aimed at preserving data integrity.

>well, there maybe something in this, but for me ranked at the very bottom. Would you agree on this ?
>But maybe, just maybe you think a little differently than I do. See my comment on the next;

I don't think so. Probably a problem in the way I expressed it.

>>
>>Fox native tables are made for the desktop. If folks need a backend server, then get a real one not a pseudo-one.
>>
>
>About the pseudo-one sec : again you are right, but IMO not with the objective in mind : this is about the wish for letting native table code run with a remote DBMS. Okay, this may not be exactly how Jim put it in the first place, but I think it was legitimate to rephrase it to that (as I did).
>
>About the first part of your paragraph : I wonder;
>What you (litterally) imply, is that without the remote DBMS -and which really wasn't there over 10 years ago- we were all working single user ?
>I am pretty sure that this is not what you wanted to say, but said it anyway ;)
>Well, where I bought my beautiful box "Multi-user FoxPro" some 15 years ago, this really was multi-user, worked with native tables of course, and the desktop manipulating them being on the server. Yes, the FILEserver.
>Let's please not make the mistake that the phenomenon Fileserver is obsolete or so, because it just is not. This, of course, by itself does not imply that a DATABASEserver would be worst or not applicable. It is just another phenomenon, existing since (I think) Oracle came with an NLM for Novell.
>I could give you a few pages on my personal (!) opinion why the principle of FILEserver is faster, better, more decent, more logical, etc. than a databaseserver, which I won't give because nobody would agree anyhow, since another topic is more strong : DB-independency. And I fully agree !
>BTW, my emphasizing on the fileserver being "better" sure doesn't come automatically, and the app has to incorporate many many things in order to have those statements of mine justified.
>
>So, this is no discussion-point (agree or not is not important to the real subject here) as long as you agree that native tables were not created for desktop-use only (which I translate to sort of single-user).
>To be sure of what I'm saying : our (VFP5) ERP-app has many thousands of users, amongst which hundreds on one physical system (fileserver), not having problems with corruption (except for one, but that is a Novell issue), and where no user notices the other (100) being there. Such a server contains 256 MB of memory, and try THAT with a remote (SQL) DBMS ...
>
>Not prooving anything, but putting your lines in some perspective ... :))

I don't think we disagree here, but let me do clarify. When I say something like native tables are for the desktop, it doesn't mean that the data shouldn't be on a LAN. It simply means that the data munging occurs client side. In fact, in my situation, I don't even believe that moving the data to SQL Server is necessarily the right thing to do. I don't have a choice, however. In my case, I'm not dealing with a high number of uses, there's little, if any contention for record locks, and security can be adequately handled through network rights. However, as I stated, this decision wasn't up to me.