>My ODBC DSN class may be of help in creating your connection. You can use it in a VFP app to create a connection using SQLStringConnect() function where you can pass the userid and password. Then you can use SPT to retrieve the data from Oracle and transfer it to your VFP tables. There really is no shortcut to getting the data int VFP tables. Now if you could convince the powers that be to just use the data from Oracle in remote views or SPT, then you could bypass this whole transfer thing.

Well here is the story. The data is from a database that resides in an Army system. For the past 8 years we have had a duplicate of their data here a Crane. Why did we have a duplicate, well that is because the data at the Army side is in a System 2000 Heirarchial and held on a mainframe that is not easy to get to and not very user friendly. So we asked if we could come to their base and provide programs that would unload their data (I used to be a COBOL and System 2000 expert) so that we could bring it up here in a fashion that would be easier to access. The agreement was set and in place. So we brought up their data in a FoxPro database. Well over the years we have improved the way users can get to the data and use it. FoxPro is very flexiable. The main thing we did was to index the memo data so the users could look through the 500,000 records for data in the remarks field. Something they could never do before. This one change skyrocket our system for use by users around the world and we even have several registered user from the Army base that holds the data.

Well jump forward to today and the Army requested that the old COBOL/System 2000 system be replaced with an Oracle system and Cold Fusion interface. They converted the data over, but found that the new web system was not nearly as robust as ours for querying and reporting data via the web. So they requested that we still maintain a duplicate. So you see where I am at. They found that Oracle could not perform the index query on the remarks field and that their speed was not as good as ours. I have no control over what they do in the Army as far as computers, servers, software or anything. I just have to work with the Oracle file. But now that we have the data here in our Oracle system, I can get the Oracle experts to experiment with different ways to unload it so that I can load it into VFP in a better and quicker manner. Then we can instruct the Army on how they could do it on their side. So we may not have to deal with a dump if we can develop a better way to extract the data into something my conversion programs can read.


>
>>Well what I am trying to cut down is the several read and writes that need to be performed.
>>
>>The conversion phase will go something like this:
>>
>>WRITE Oracle Dump Gets Produced
>>READ Oracle dump is FTP'd to our system (135MB)
>>READ Oracle Dump Gets Read into our Oracle System
>>READ ODBC Data is read by VFP one record at a time (as this is a complete load each time)
>>WRITE Conversion Process Writes the data into acceptable VFP tables.
>>WRITE Master VFP Tables are copied over with new converted data tables.
>>
>>So what I am looking for is the method that would be the fastest to get the conversion done and it needs to be automated (done at night while no one is around).
>>
>>Which brings up another question on ODBC. How can I get my VFP ODBC connection to Oracle to save the password and quit asking me for it? The process cant be too automated if a password has to be input to get the job done.