Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Dbf size and LAN performance
Message
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00238375
Message ID:
00238397
Views:
11
>Hi,
>I have a general question concerning DBF size (bytes) and LAN performance. We have a table that is 80Mb (since system went live 1 year ago). We expect this dbf to more than double in size each year. (ie. next summer, this table will probably be 200mb+) There is also an FPT associated with this table that is currently over 8Mb.
>
>Should we be concerned with performance over time? Especially when issuing a USE command? The network is already 100Base/T with a switched hub. I've already experimented with taking this app true client/server with MSSQL, but it looks like it could be a daunting task, to say the least, even though the app is already completely based on local views w/data behavior classes. Even reading the recent article in Foxtalk on taking a VFP app client/server did not put my worries to rest if we decide to go that route.
>

The size of the file won't be an issue for USE, but obviously, the more data you have to move over the wire to solve queries, the slower it will be. Ensuring that queries are written to take advantage of Rushmore technology will help keep query times reasonable, but obviously, if you have to move a 200MB file over the wire a record at a time to do something, it's going to take longer than to read a 2MB file.

If you find that solving queries is creating too much network traffic, and the results of queries tend to be small compared to the size of the minimum data that must be read to rsolve the query, you'd be best off considering moving to using a backend like SQL Server. This will reduce network traffic, in that SQL query statements fcross from the client to the server, the server massages the data (hopefully located on its local storage) and then just the recordset satisfying the query needs to come back across. A backend can also help with other things, for example, SQL Server can deal with larger physical tables, can be scaled more easily, can provide better security, journalling, logging and the like.

The good news is that moving to a backend can have minimal impact where your current app uses local views at present; switching to a backend will entail changing to remote views rather than local views, but you will have minimal impact on your existing application code. OTOH, remote views won't take fullest advantage of some backend features, but will address network traffic issues nicely without having to do massive rewrites.

>Thanks for any input, words of wisdom, re-assuring words, etc.
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Reply
Map
View

Click here to load this message in the networking platform