Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Create Connection / SQLConnect
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00161962
Message ID:
00162159
Vues:
26
Mark,

I hope that it is Kosher removing the original communications but the email was getting a little long.

Sorry about the confusion; at the time of the original message my mind was so muddled from reading help files and manuals and running around in circles that I probably didn't include all of the necessary details.

What I'm trying to do from a VFP6 app is to connect to a user's MS Access file and then use SQL SELECT() to get the information into VFP where my app can then use it. Eventually I'll want to build in the same functionality for MS Excel.

My confusion in reading the help files is that a lot of functions will talk about "Named Data Sources" and one said that it was for connecting without needing a "Named Data Source" and then I was reading the SQLConnect(cConnectionName) command that said that cConnectionName is created in CREATE CONNECTION hence my use of both of these commands.

I started looking up the commands that you used in your example to register a DNS and noticed that they were Visual Developer commands and not commands that could be directly run from VFP so I started reading the VFP manual some more.

I then discovered the SQLStringConnect() function that makes the connection with the connection string that I had built without any need for a DNS but just using the generic "DSN=MS Access 7.0 Database;". After that I discovered the SQLTabel() function so that I can present the user with a list of the tables in the choosen database and for him/her to pick the table that they want to use.

That's about all I've had time for so far other than to see that I can't issue a SQL Select() on the chosen table directly from VFP but that, apparently, I need to use the SQLPrepare() and SQLExec() to issue the SQL Select() using the data source engin or whatever. I still haven't done this yet. Once I have a cursor that I can use in VFP then I'm free and clear other than all of the error traping (does Acess have all of the same field naming conventions as VFP, etc., etc. and if not what do I do about a cursor that is not VFP complent?).

Anyway, I feel that I am making headway. My biggest stumbling block seem to be that my need is for VFP to connect to Access but all of the examples are for SQL Server to connect to something else using an established Named Data Source.

Any light shed would be greatly appreciated since I'm still stumbling in the dark.

Thanks again.

Ed



>I am now confused. If you have the user select a database (DBC), why do you need to create a connection to it? Can't you just issue an OPEN DATABASE (User_Selected_DBC) command and start opening tables or views from there?
>
>To create a connection to a *remote* data source, you have to have a DBC open. A connection is a component of a DBC. To create a connection, you have to first create a DSN either via the ODBC Administrator or programmatically like my previous example.
>
>The reason I created a DSN and connection to a VFP DBC was for an application that needed access to limited data in an existing app's DBC. This second app has its own DBC, so all I needed was a remote view to some of the data in the first app's DB. In the second app, I check the registry to see if the VFP ODBC drivers have been installed. If not, the user gets a message to contact me for support. It then checks to see if the DSN has been created. If not, it is created programmatically. The connection already exists in the second apps DBC. Because I check for everything being setup properly, I will not get any error since I terminate the app before any view is opened if any component is missing.
>
>I designed it this way as a somewhat secure method of accessing personnel data on a Novell network. The second app has Novell Read-only access to the DBC files and certain DBC/CDX files from the first app. The user can not File-scan, edit, erase or create anything in the first apps DB directory. But since the data can be read, I can now create a remote view of the data in the second apps DBC.
>
>I will be using an encryption library (Cryptor, NetLib, etc.) to secure the data from the first app to prevent hacking from the 2nd apps DB.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform