Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Who really uses the VFPOleDB.1 provider?
Message
From
04/10/2006 01:06:07
Thomas Ganss (Online)
Main Trend
Frankfurt, Germany
 
 
To
04/10/2006 00:40:44
General information
Forum:
ASP.NET
Category:
Databases
Environment versions
Environment:
VB 8.0
OS:
Windows XP SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01158763
Message ID:
01159222
Views:
27
>>What was your intended HW architecture for the OLEDB ? Unless you planned for a box with lots of cores to run the OLEDB-queries on tables sitting on the same box I don't think you will have a scaling problem very soon, if you can live with the 4 gig size limitation. If your business calculation has no room for the licensing cost even if the traffic is high enough for Express version to be hard pressed (AFAIR - pls verify yourself! 1 Gig of RAM alotted and only one CPU used - dunno if socket or core is specified) you still have some time left to check out your other options. Yes, it will cost YOUR time and money - but you have a running program and at least you have backend portability cost already verified afterwards <g>.
>
>I am not sure what you suggest. Are you saying that SQL Express would be an acceptable solution for the backend?

I am saying it might be... As I have no idea what load must be handled, I was taking the long way around via the planned usage of HW. VFP and the OLEDB provider will work best if the thread actually querying is running on the same box - otherwise you always have LAN latency bogging you down. As SQL Express is only limited in
4 gig size of database (should be easy for you to guesdtimate the problem factor)
1 gig of RAM used (as SQL server is not using the OS system cache, this hurt factor depends on number of users and complexity of queries)
1 cpu used (IF here the same licensing schema is used as in windows, buy a quad core Intel in november...)

you should be able to decide on more than "feel", because you can test and/or estimate. There are only a few query complexity/data size/user number/HW architecture combinatons I can think of where the OLEDB provider is clearly the better technological choice from a free cost and scalability perspective.

YOur situation (complex read queries) might be one of them - for instance if many OLEDB queries are running on dbf-file-data cached in many gigabytes of RAM running on multiple CPU's. Asking about your HW is a roundabout way to get an estimate for my mental picture...

regards

thomas
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform