|
This situation is uncommon, but quite possible. Most FoxPro developers who start working with SQL server after they have worked with FoxPro call it "too stupid database" or say that "SQL Server - it is just SELECT, INSERT, UPDATE, DELETE". As a rule, people say this when trying to create stored procedures with T-SQL or
PL-SQL (Oracle).
The problem does exist, and the problem is serious. It is simply too difficult to write a complicated T-SQL procedure that would do what a FoxPro program does. We do agree with the opinion that T-SQL and PL-SQL are tools of torturing the developer, and we really have our reasons. It goes without saying that T-SQL and PL-SQL support complicated functionality, but such procedures will cost you much effort (and health) both at design time and runtime.
So our advice is: don't waste your time. Create a COM (automation) server in VFP, place it on your SQL server and write procedures which will select data from SQL Server databases, process the query results with the help of previously written FoxPro codes; then send the result to the client. Writing the result into SQL Server temporary databases - as you cannot switch transactions off - will also kill your application. Using FoxPro for
complicated - as well as any - algorithms has one more advantage: if you use T-SQL inside SQL Server to access and modify data, you will have to select data into internal cursors. It's much easier to select the data into FoxPro cursors, as we cannot doubt FoxPro abilities when used as a remote server in "Client-Server" technology.
We've seen many websites created with FoxPro only, where FoxPro is used as SQL Server (data access) and ASP (HTML generator). But that's where 2Gb limitation comes into
view. For example, if the size of your database is ~ 70 Gb (and this will happen if your application works with really large numbers of customers and monitors every transaction), and you select a large amount of data into a FoxPro cursor, the size of the resulting cursor may exceed 2Gb and your application will happily crash. One may think of using several (dozens) of FoxPro cursors, but we firmly believe that in this case it is better to use ADO.NET instead of FoxPro automation
server, as actually, when FoxPro works together with SQL Server as an automation server, it does the job of
ADO.NET.
|
