Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How MS/VFP could make millions (revisited)
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00790030
Message ID:
00790122
Views:
17
Hi, Terry.

>Think of a SEEK/SCAN construction as one isolated transaction per record (in fact, that's preety much what it is).
>
>I was suggesting that the programmer could USEEX() or SEEKEX(). The way it behaved would not be at all like they behave (in legacy)on a LAN. But, the results would be the same. Why does CREATEOBJECTEX appear to persist - because MS engineered it that way. Why don't USE, and SEEK persist and easily negotiate the architecture: Because MS engineered them that way.

I think that I can make my point obvious enough. Your UseEx() or SeekEx() is not the problem. The problem is performance. As I told you, you can actually do a use over th Internet. Just map a URL to a virtual directory on your IIS, enable all rights over that virual to the IUSR_ (and let's forget abot security and even suposse that all these steps are taken care by some magic process for now), and you can do what you intend.

In fact, when mapping the URL, you're creating basically that "invisible" persistence you want. Now, write some simple code as:
* This is a 10,000 records table on your mapped URL
Use I:\MyTable order Name
lcString = ""
scan
   lcString = lcString + MyTable.Name + chr(13)
endscan
Now, this code (assuming it serves some purpose) would be an overkill to run. Why? Because you have to remotely establish 10,000 connections and disconnections, and transfer the whole index across the wire IN PIECES. Why? Because this code doesn't allow the engine to know if you'll be accessing 1, 5, 300 or 10,000 records. The SCAN is intended to work ONE record at a time.

Now just think this other syntax:
* This function does not exist, but it's absolutely feasible.
RemoteSQL( "Select Name from MyTable order Name", ;
 "http://www.TerryThurber.com/DataBase",
 "MyCursor" )

select MyCursor
lcString = ""
scan
   lcString = lcString + MyCursor.Name + chr(13)
endscan
Well, this one can perform quite well. Why the difference? Because it sent a SINGLE request, followed by a SINGLE resultset (no matter the format in which it came back, or how big it is). Of course, 100 records will come a lot faster than 10,000, but anyway, this approach is a lot more efficient, because everything was done in two single steps (response/request).

And there is no way in which the first code sample could be optimized server-side, because you're accessing a record at a time. If you have to tell the server: "I'll start here, and end here", then the flexibility you want is lost, because you'd have to wait until the end to use the data.

Is this clear? I don't mind keeping arguing about this topic. As you can see, I like it. 8-)

Regards,
Previous
Reply
Map
View

Click here to load this message in the networking platform