Alejandro,

To create an oledb data source create a text file and rename the extension to a ".udl"

Now double-click on the file and an oledb configuration applet comes up. U can treat this the way you treat any other 'foreign' data source in foxpro. You run spt commands native to that data source.

But you can also link to the data programmatically as in this example. It is an extract from http://fox.wikis.com/wc.dll?Wiki~VFPOleDBProvider~VFP.

Sorry I hadn't been in here for a while, hope you have found a solution to this. But here is an example:

*!* **- point to a dbc
*!* Provider=vfpoledb;Data Source=C:\MyDbFolder\MyDbContainer.dbc;Collating Sequence=machine;

*!* **- point to a Free table directory
*!* Provider=vfpoledb;Data Source=C:\MyDataDirectory\;Collating Sequence=general;

*!* **Force the provider to use an ODBC DSN
*!* Provider=vfpoledb;DSN=MyDSN;

** the example here uses dbc sample database
cConnectString = [Provider=VFPOLEDB.1;Data Source=] + HOME(1) + [Samples\Data\testdata.dbc;] + ;
[Mode=ReadWrite|Share Deny None;Password="";Collating Sequence=MACHINE]


oConn = CreateObject("ADODB.Connection")
oConn.ConnectionString = cConnectString
oConn.ConnectionTimeout = 30
oConn.Open
cSQL = "select * from customer"
oRS = oConn.Execute (cSQL)
if oRS.EOF
? "No records found."
oRS.Close
oConn.CLose
RELEASE oRS, oConn
RETURN
endif

do while !oRS.EOF
? oRS.Fields("Cust_id").Value + " - " + ;
oRS.Fields("company").Value
oRS.MoveNext
enddo

oRS.Close
oConn.CLose
RELEASE oRS, oConn
RETURN


Sergey, about your comment that OLE DB are slower. I am not going to argue with that and you are very likely right. I have never compared them like for like. But does I said, "performance" and you said "slower" implying speed. Is performace speed? In other words are the best performers always the fastest? Just a thought.



>Hi Mathias,
>
>I meant client rather than terminal.
>
>Up to some days ago the accounting app that maintains the database got its data from a local Pervasive (btrieve) engine which got/saved it directly from/to the data files in the server, similar to the way VFP works. The Pervasive engine in each client was properly set up and reports were produced reliably.
>
>After a recent upgrade I find that now DacEasy must be run in the file server as well as the clients. When running in the server it acts as a true database server feeding data to the clients via a service running in each client.
>
>During the DacEasy upgrade the local database engines lost the configuration except in the development machine (very sad) so now reports can only be run in the development machine leading to a rethinking of the reporting process. I acquired a ClassicSoftware product called Data Manager Enterprise which is able to export btrieve tables to many formats, including VFP via OLEDB. The plan is to export DacEasy tables to a VFP database, report from those and then delete the exported data. It is suppossed to be fast compared to ODBC access.
>
>So that brings me to the original question which is how do you give access to VFP data via OLEDB. Is there an equivalent of the Windows ODBC administrator where you set up a Data Source that is then accessed by the external app (Data Manager Enterprise in this case). It seems funny to talk about giving access to VFP data when what is really happening is that the VFP tables are getting filled, but the mechanism is the same (OLEDB).
>
>I am totally new to this. Please forgive the ignorance.
>
>Thank you for the help,
>
>Alex
>
>
>>Alejandro,
>>
>>As a rule of thumb "OLEDB components offer much better performance than ODBC".
>>
>>You have used the word "terminal" here, is this "client"?
>>
>>I thought you could avoid configuring clients if you let the server do the actual reporting as well?
>>
>>Just a thought.
>>
>>Regards
>>
>>
>>
>>>Hi,
>>>
>>>I am trying to export data from a btrieve database using a tool from ClassicSoftware called Data Manager Enterprise. In the process I need to indicate the destination of the data as either an ODBC or OLEDB "source", though it will actually be receving data rather than providing it. I believe this would point to a DBC, though I am not sure if that is correct or how to go about it.
>>>
>>>It would be nice if the method chosen doesn' t require that each terminal be individually configured as is the case with ODBC. Does this mean that OLEDB is better? The data will only be used to create reports and then deleted.
>>>
>>>I'd like to create an empty DBC programmatically and then export to it the btrieve data using the tool mentioned above. The parameters required for the export will be stored in a special file created beforehand.
>>>
>>>All help will be appreciated. Thanks,
>>>
>>>Alex