Jim,
>
>I'm sure that Walter will give you a far more complete point-by-point reply, but I feel I've gotta answer a few things. . .
>
>>Walter,
>>
>>Rather the giving you two replies, I’ve compressed things into one.
>>
>>You’ve said that you don’t believe that VFP through its tmp files does any caching. I may be mistaken, but I seem to recall a tip in FoxPro Advisor a few years ago regarding restoring data that had been lost due to a system crash when the table was open. It would seem to me that, if this is the case, that VFP does indeed engage in some internal buffer of some sort.
>
>There's cacheing, and then there's "cacheing". Personally, I would qualify cacheing (or "cacheing") as RAM-resident copies of (parts of) files/tables and not regular .TMP (or whatever) file/tables. In other words, I would still call it a cached (or "cached") entity if it went to SWAP storage (it is a surrogate for RAM) but not if it went to any HD or out-processor (new term) media in a regular 'file' format.

Semantics, that's all.

>>
>>You said, “I think you make a complete invalid assumption here. Though I immediately agree that you're right about the network trips, I'm talking about the I/O needed to complete the transaction on low level I/O. When comparing the two you should compare what is happening internally on I/O level. I could easily build a out of process VFP server, stored on the same machine as the database, that accepts the same commands as you send to a SQL server. You'll see that the trips across the network are just the same. In fact you'll see that this VFP application is just like a mini SQL-server, a server DBMS based on ISAM tables.”
>>
>>The fact is, Walter, you couldn’t do what you’re implying here. There are a couple of problems in your out of process server scenario. First is that even though the application resides on the server, it still has to be loaded into client memory and do its I/O over the network wire. Even if this weren’t the case, it still has to position the pointer and make updates. Finally, what good would it be? After all, it’s apartment model threaded, which means it could handle only one transaction at a time.
>>
>>By contrast, and again using SQL Server, any requests, whether for data or updates, are handled client side. Further, it manages a pool of threads, and can and does handle multiple transactions at once.
>
>I think that you are simply wrong when you attribute any physical I/O activity to "position the pointer". I'm ready to bet that it is a wholly "logical" thing, calculated based on displacements.
>Handling multiple threads (versus one or whatever) is strictly a software design function and has nothing whatsoever to do with "ISAM" or not "ISAM".

When the updates are made, the pointer has to be positioned in an ISAM table. This applies even to SQL Server, if cursors are used in an ISAM manner. There's no debate about it. You'd be dead wrong to say otherwise.

>>
>>You said, “When talking about low level I/O you'll see that the server DBMS does a lot more than just searching for a file position, update the record etc. In a server DBMS other facilities like authorization, advanced locking schemes, isolation levels, transaction logs and replication, come into action when updating a single record.
>>
>>This all has totally nothing to do with ISAM itself. Its just that ISAM tables are often accessed from another networkstation than where it is stored physically. In server DBMSs this is all encapsulated onto one dedicated PC. To do a fair comparison, you should compare ISAM based DBMSs with server DBMSs where the database AND engine are BOTH locally installed. Then you should compare the effectivity of ISAM related storage with DBMS related storage. You'd come to the comclusion a server DBMS does a lot more I/O because it usually has a lot more (and complex) facilities it should take care of.”
>>
>>Of course, but it’s all handled on the server side, not the client. However, I was talking about the scenario where the data is not stored locally.
>>
>>>Yes but you have to position the read pointer in either case.
>>
>>”Just like a DBMS does internally (among other things) to be able to read the contents for the record which is needed to fire triggers (and begin able to query the current value), for replication and the transaction log.”
>>
>>At least with SQL Server may not have to position any record pointers, since it probably has internally cached the 8K pages involved and writes them back changing only the data on the affected pages.
>
>Every computer function that operates on 'records' - that is, distinct portions of a file as opposed to a whole file - has to know where it is reading from NOW and where it wants to read from NEXT. This is a LOGICAL function of ALL such computer functions, xBase or otherwise. SQL Server surely has "record pointers", though the designers may have chosen to make them unavailable to the user.
>In addition, ALL computer functions that operate on 'records' - as above - have them internally cached (sizes of pages (or RAM if not logically 'paged') may vary) in at least a "buffer". Generally a "buffer" is a term used to describe a area of RAM holding the (limited) "records" of current interest whereas a "cache" generally holds extra, in anticipation, for performance reasons (and only performance reasons).
>Furthermore, no system anywhere writes back only changed data on affected pages. None. All write back an entire record when even a single byte of that record has changed. This is so for (logically) paged files too.

I never said that only portions of records where modified.
>>
>>“And though of course you can describe what you want to get with SQL server, internally in both stategies very much the same is happening (on low I/O level). You only took the freedom to look at SQL-server at a much higher abstraction level and compared this with the low level I/O that xBase languages employ. You're forgetting that SQL-server does more or less the same as xBase internally. The difference however is that in the case of SQL server all is one one machine, while in the xBase example the engine is on the client and the database is on the server. This is not what a regard a fair comparison, and has nothing to do with ISAM itself.”
>>
>>You still don’t understand the difference here. An RDMS such as SQL Server is set-based. You may or may not cause the entire table to be read into memory (both server side and client side). An ISAM DBMS is file based. When you open a table, you have no control over how much of it is read into local memory for manipulation. When you retrieve a result set from such a backend server, you only get what you ask for. This isn’t an abstract difference. This is concrete.
>
>It looks like it is you who is not understanding, George. Not to mention that you are introducing a new term - ISAM DBMS - which we have all called RDBMS for all these years.

No I did not introduce the term ISAM DBMS, I simply dropped the R for Relational, since all ISAMs aren't necessarily relational. But this has nothing to do with the issue

>"Set-based"/"file-based" have nothing to do with ISAM or not ISAM. These terms may belong in another discussion, but not in this one.

First, ISAM is not set-based. Period. End of story. Properly used, SQL is set-based. This is an inherent difference in the two models. To submit otherwise, is pure nonsense.

>In either case (SQL Server or VFP) one could have some control over how much is read into local memory. Both, I submit, give us only indirect control, but some control nevertheless. The size of the machine's RAM, the size of the SWAP file, manipulation of internal controls (more in SQL S. but some in VFP too) the presence (or not) of (appropriate) indexes.
>And again, that SQL Server delivers only the result set is a function of the software design. VFP does this too, by the way, when we use it's SQL commands. Sure, there's some extra I/O in the beloved, but not much if carefully done.

Nevertheless, it is there and VFP in order to perform must bring at least a portion of the file, plus, if available, all the applicable indexes across the wire when data is on a remote server.

>>
>>When you send updates back across the wire, with ISAM they happen one-by-one on the client side. With an RDMS, you send back the entire set for processing on the server side.
>
>I don't know this for sure myself. But, whichever is the truth, there's likely not much difference between the two. With SQL Server, given that I intend to update any of a group of records, it has to give 'me' those records. I'll process them to my heart's content, then issue a Update. At this point I don't know if they come back to the server 1-by-1 or in 1 giant stream. But this hardly makes a difference in the overall scheme of things, because it will be exactly the same way for VFP. VFP will likely send only the records that have changed, so it might well come out ahead!

You need to do some reading. You really don't understand.

>>
>>As far as the low-level I/O, I think I know a bit about this, and speaking to a SQL Server vs. VFP, they are very different.
>
>Forgive me, but it doesn't look like it. Do you know how a cylinder/head/record position is calculated for a specific record (be it a 'page' or just a 'record')? How a scatter-write is accomplished?
>SQL Server and VFP do have very different I/O PATTERNS, but they have remarkably similar storage and I/O mechanisms. Near identical on the basic stuff as I read things! SQL Server does much much more I/O for a variety of important reasons, but at its heart it is still doing its I/O the way VFP does when data and indexes are concerned. If one is "ISAM" then the other is too.
>
I've been getting testier by the moment with this, but the above...well...

First, and foremost, I've done direct reads and writes to disks via assembly language on other platforms. Second, I've done the same by interfacing through a assembly language library under QuickBASIC and DOS 5.0 to access the the actual ROM BIOS interrupt routines. What me to give you the extract interrupts? Since, however, the advent of Windows, I've concentrated on the API side of things, especially since under Win32 there's no means of accessing the ROM BIOS interrupt routines directly. So, IOW, to answer your question, yes at one time I did, but do no longer.

However, by low level file I/O I certainly meant the API side. Frankly, there are two questions that you'd have to answer no to, that I'd answer yes. Question 1: Has he written in any post since 1/1/2000 any reference to exactly how Windows opens files? Question 2: Has he ever posted any contribution on the UT demonstrating this? I'll let the readers of this figure out who knows what.

Lastly, your last sentence is nonsense. If you don't see, don't understand, comprehend, or even acknowledge the differences, I can't teach you. As far as I'm concerned, your portion of this thread with me ends here and now. Don't bother replying, because it'll probably be more of the same, and if so, I won't engage.