We tried using ADO and we finally got it to work. Initially, it was working slowly using my PC which really puzzled us since it was suppose to be flying. So we tried the same code on another PC and it was flying on that one. That leaves my PC as the culprit.

We finally traced it to the ODBC connection to the SQL database on the SQL server. My PC was using Named Pipes instead of TCP/IP which the other PC was using. After I got that changed, my update speed went flying (500 records in less than 2 seconds).

We're still testing using conventional methods i.e. updating remote views then doing a tableupdate and using ADO recordset. So far ADO is very much faster.

Thanks for your time and help.

Arriyel

>Definitely 1 record per second is crawling, but I don't think I'd call 3 to 4 records per second very fast either. So, yeah, maybe your constraints are slowing things down, but it still doesn't sound very fast to begin with. I can do a simple update of 1000 records in less than a second ... I think it's even less than a tenth of a second.
>
>Something else is going on here with these horribly slow response times, but I don't have a clue what it might be. Maybe one of the SQL guys will jump in here with a suggestion ...
>
>~~Bonnie
>
>
>
>>Hi,
>>
>>The SQL server is on another machine. A dedicated SQL server that holds databases for multiple applications. It's a W2K PC with PIII 800+MHz CPU and 256Mb of RAM with a 40Gb hard drive.
>>
>>The database is not that large yet but it can be. We estimate that it would have 100,000 records on some tables but not more than that. The 'Clean' data base (all look-up tables loaded) would be fairly small with the largest table having aroung 30,000 records.
>>
>>The current problem is that loading the look-up table will take hours of processing if the current speed is used (about 1 record per second). We suspect that the constraints on the database is the culprit since when I was sending the updates before the contraints were applied, it was fast (about 3 to 4 records per second).
>>
>>Were currently trying ADO recordsets now to see if that would produce better peformance.
>>
>>Thanks,
>>Arriyel
>>
>>>Arriyel,
>>>
>>>Hmmmm ... well, the slow speed is a bit harder to diagnose. Where is your server located? On another machine or locally? If it's another machine, is that machine set up, hardware-wise, properly for a server? (lots of RAM and diskspace and fast processors). It shouldn't take that long unless you are testing against a very large database on your local machine (which wouldn't have a server configuration).
>>>
>>>
>>>~~Bonnie
>>>
>>>
>>>>Hi,
>>>>
>>>>I tried your suggestion and it works since I see all the records I updated in the remote view appear in the SQL table. Problem is that it is still very slow. I updated 25 records and it took 25+ seconds before the tableupdate() returned control to VFP. I'm testing it with a larger table (>400 records) and it is taking longer that I expected since I started it 10m minutes ago and it still hasn't finished.
>>>>
>>>>Do you have any other ideas?
>>>>
>>>>Thanks;
>>>>Arriyel
>>>>
>>>>>Arriyel,
>>>>>
>>>>>>then doing a tableupdate() but it would only add 10 records or less with the rest missing. Is there a setting on the SQL server I need to set?
>>>>>
>>>>>Yes, for a remote view you probably need to use the following command:
>>>>>
>>>>>

>>>>>DBSETPROP("MyView", "View", "MaxRecords", -1)
>>>>>

>>>>>
>>>>>I believe it may default to 10 MaxRecords.
>>>>>
>>>>>HTH,
>>>>>~~Bonnie