> Having the form on the server (or in an EXE) is not as efficient as you
might
> think. The form or exe is not copied to the PC, it is accessed
> repeatedly.
I ran into this back in my floundering VFP3 days, when I did not know any
better. I was told to create a formset that could be updated once on the
Server so all users would see the newest version of a very data intensive
application. So, I compiled the project as an .exe to be fired from the
Server as directed (my gut told me it would be a problem, but what did I
know?) My first indication that something was wrong was when I was doing
some training and one of my colleagues challenged the students to all load
the app at the same time, with the .exe running on a P75 Server with 64Mg
RAM! CRASH!!! Never challenge anyone to do anything that has not been
thoroughly tested first <g>... ("Uh, Dave, that is not a good idea...
Okay, you'll see..." <g>...)
Anyway, the forms would take a long time to load into local RAM, about 1.5
minutes on a 100BaeTx connection, even with a single user hitting it. Once
I broke away onto my own, and put together my own VFP creations I began to
use all forms and form sets on the local PC (compiled as .exe files of
course). To get updated .app files onto the local PCs I used a technique Ed
put togther (available for free, but I can't recall where in his archives it
is. It is called "launcher"). Launcher is compiled as an .exe file, and it
compares a local .app to a version on the Server. If the Server version is
newer it copies it locally. Once it is happy that the local PC has the
latest compiled .app it fires it off and away we go. No more Server based
forms and formsets to keep all users current, no more manual
uninstall/reinstall with new versions, and no more manual copy from Server
routines. Quick, dirty and simple.
Gil
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Mike yearwood
> Sent: Monday, March 24, 2008 3:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Tables in the Data Enviroment
>
>
> Hi David
>
> > >For all practical purposes doing a USE <table>.... does not
> bring down the
> > >whole table. The only exceptions I've seen to this is where
> the total table
> > >size was small. I can't remember what the cutoff was. Maybe
> 64k? Even then,
> > >since it's so small it's not really noticed. But my
> gigabyte-size tables
> > >open in blip of time over a 100Mbps network.
> > >-Charlie
> >
> > Hmmmm I created a blank form and dropped two tables into the data
> > enviroment. One table has about 2000 records and the other about 3000
> > records. It took 15 seconds for the form to open on the clients network
> >
>
> You've got something else going on. Forget the form for a second and
> do it the hard way as a learning experience.
>
> Create a table with a million records. Put it on the server. Time the
> length for these 2 commands. USE TABLE. GO BOTTOM. Then compare that
> against the time required to copy the dbf file. I'm surprised this
> long-standing myth is still around.
>
> Now obviously if you do something to force VFP to get the whole table,
> it will do it, but the reality is you should be avoiding that. If you
> have multiple indexes in a CDX, but your query only needs one of
> these, it does not read the entire CDX file.
>
> Now, if you have a DBC on the server and if there are views, there may
> be contention for the DBC record holding the view definition. Having
> the form on the server (or in an EXE) is not as efficient as you might
> think. The form or exe is not copied to the PC, it is accessed
> repeatedly.
>
> Non-Rushmore optimized commands like GO TOP and GO BOTTOM with filters
> and/or SET DELETED can take a long time to skip to the first matching
> record in the filter, but still it is not reading the entire dbf or
> cdx.
>
> Mike Yearwood
>
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
