Walter Meester
HoogkarspelNetherlands
General information
Category:
Forms & Form designer
Environment versions
Network:
Windows 2008 Server
>>>I would never use SEEK() in a VFP, SQL SELECT to lookup a value in another table, unless there is A VERY GOOD reason to do so. Just an extra join would do the trick just fine, even if it ends up a few ms slower.
>
>I use SEEK against huge lookup tables if I cannot be sure that the execution plan for theoretically elegant SQL won't involve intermediate resultsets >2gb that crash the system. As you note, sometimes there's a good reason- and static lookup tables is one of those. SET RELATION can be even better, but lets not go there. ;-)
Personally, I do not see a very good case for having huge result sets that need to be processed in VFP. The last huge VFP-database I got lies many years behind me. But again I realize there might be certain cases that might justify doing that. However in general it should not be done. SQL server is cheap, robust and fast.
>As for a production system using SEEK against live tables: probably the most efficient rewrite would involve Database Views filtered on each of the indexes used in seek, and then try to automate the conversion. Tricky effort unless the code uses SEEK() with named indices...
>
>Re Datasessions: we've done it both ways. Apps written in the VFP3 days allowed multiple forms having their own datasessions to avoid screwing up activity in other forms, especially if adding a record. More recent work uses datasessions for privacy- iow switches to an empty datasession when interfacing to other systems. Most of the AI stuff I do predates datasessions and wouldn't benefit from them. I don't think there's any one answer.
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only