Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
ADO and CursorAdapter - letting ADO do the work?
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Visual FoxPro:
VFP 9
OS:
Windows Server 2003
Network:
Windows 2000 Server
Database:
MS SQL Server
Divers
Thread ID:
00973485
Message ID:
00974304
Vues:
35
Hi Aleksey,

>It is possible, an example is below.
>However, I'd like to know more details about the following quotes:
>
>Could you describe specific scenarios (preferably with code)? What exactly is inconsistent? Why the way CursorAdapter passes parameters doesn't work for you?

The following are my impressions of the CursorAdapter that I've gotten over the last few couple of weeks of working trying to get a variety of different code to run though ADO.

As background, my goal in what I was building was to wrapper an existing Sql Passthrough class that is a disconnected SQL engine (ie. no cursor attachments, but just an engine that allows running any SQL command) to work with ADO. One of my clients has a large app based on this existing interface and it basically uses raw SPT syntax (inside of business objects, calling this SQL wrapper class) for all SQL. The business objects generate SQL for many things like updates, new ids etc. The engine work of raw SQL nothing is updateable - the framework handles this.

My primary reason for using the CursorAdapter in this case has been to convert converting ADO recordsets into cursors. The ADO requirement is for the Unicode of an application I'm doing work on. At first the CA seemed like a perfect solution to the translation problem because it works with SPT syntax. But it became obvious real quick that hte CA doesn't fit this model very well as a complete solution.

The cursor adapter is very powerful and I suppose it can do a lot of things that I haven't even figured out how to do, but the public interface of this object is complex because of it's multi-overloaded properties. It's not a good tool to plug into any sort of existing framework because it's tough to integrate. If you truly wanted to abstract data access without ever having to talk to ADO, or SQLSPT functions or XML, the CA doesn't make this process of integration easy at all. It works reasonably well as something that goes directly into an app, but it fits lousy at the framework level because it's hardwired into the remote Cursor model.

Its power comes from the fact that it actually works with the objects underneath (ie. ADO and XMLDOM etc.) but this also makes it a lot more difficult because you have to really understand those objects and their syntax and actually use those objects in order to properly configure the CursorAdapter so it can do its work.

With ADO, I ended up using pure ADO code to run my SQL statements because I had more control over parameters and Stored Procedure calls. For the most part the CA runs my SQL commands ok, but I did have problems with the following:

The CA does not appear to return @output parameters when no result cursor is returned from a stored procedure. If you have a SELECTCmd like:

pcID=0
Exec Test 'someparm',?@pcID
? pcID

and the SP on the server does not return a Cursor the parameter is also not returned (likely because VFP can't know that this routine doesn't return a cursor and ADO requires that non cursor queries are run with a special flag).

The other problem is not really an inconsistency of the CA, but rather something that's outside of its range of functinoality.

I couldn't use the CA for straight updates into a database with SQL commands. It's frustrating to have a tool that has the capability to perform all the core SQL and language parsing and translate the Fox syntax to appropriate SQL syntax, but then only support in a very fixed and 'connected' way - ie. you have to have a mapping cursor to update data on the server. As far as I can tell there's no way to just fire off a SQL command against the backend (other than Select and Exec comamdns that return cursors) without a cursor that's connected to it to initiate the updates. Same with calling pure stored procedures that don't return parameters.

It's a point of consistency. If I have an app and I talk to say SQL Server and I use the CA to do my updates, and now I need to do some specialty operation like call a stored procedure that doesn't return a cursor but has return values that isn't tied to an update - how do I do that? Or if I need to update a table in an unrelated database that I normally don't have a cursor mapping for?

Now I have to go ahead and go back and use the underlying objects (SQL Passthrough, ADO) to perform these actual tasks. It's inconsistent.



So, these are my opinions. Like I said, I think my needs are beyond the spec of what the CA is supposed to do, but I think the CA has all the logic for things I need to do built into it. It just doesn't expose them <g>. A great addition to the CA would be the ability to send native commands to the backend. A plain Execute and ExecuteNonQuery methods would consolidate would help considerably to fix most of these...

+++ Rick ---
+++ Rick ---

West Wind Technologies
Maui, Hawaii

west-wind.com/
West Wind Message Board
Rick's Web Log
Markdown Monster
---
Making waves on the Web

Where do you want to surf today?
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform