Walter Meester
HoogkarspelPays-Bas
Information générale
Catégorie:
Gestionnaire d'écran & Écrans
Versions des environnements
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.
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement