Depending on specifics, HTTP calls can be issued asynchronously. That would mean, if applicable to your case, that the local process would not have to wait for the API call to return in each iteration. Single-record processing would be triggered upon completion of the respective API servicing, but wouldn't stop the table scanning, at least completely. For instance, you could set a number of concurrent calls - say 20, or some other number that may be proven effective.
An example of this setup can be found in the overHere SDK ( https://github.com/atlopes/overHere). Calls to the Here location platform "Geocoding Autocomplete API" are performed asynchronously. In the AutoComplete-Async demo form, as the user keeps editing an address in the textbox control, underlying calls to the platform web services are launched and the retrieved suggestions displayed as fetched, while not preventing the user to continue his/her editing. The overHere SDK implements a callback mechanism that has to deal with object persistence and XML over HTTP (instead of simple XMLHttp request), but a simpler method could eventually be set in place for your scenario. On Mon, Aug 3, 2020 at 12:23 AM MB Software Solutions, LLC < mbsoftwaresoluti...@mbsoftwaresolutions.com> wrote: > Right...we're using the API documentation from the vendor, doing it > according to what they say. It's not super quick but then again I don't > think most people use it for processing tens of thousands of records > quickly like my client's app does. Most folks are using it to just get > a single carrier's information (it's a trucking app) at a time. > > > On 8/2/2020 8:17 AM, António Tavares Lopes wrote: > > Mike, > > > > a) is it a Web API that you may call through an HTTP library? > > > > b) and the parameters' values in each call to the API come from each > record > > in the table? > > > > On Sat, Aug 1, 2020 at 6:07 PM MB Software Solutions, LLC < > > mbsoftwaresoluti...@mbsoftwaresolutions.com> wrote: > > > >> I've got a regular process that runs, basically using key information to > >> grab data from an API and then update the local VFP database. There are > >> maybe 64000 records to process, and each record to update through this > >> process takes about a second, so to process this group would take over > >> 17 hours. Each record could be processed on its own; there are no > >> relationships between each. > >> > >> I don't want to start it and run the 64000 in a row for 17+ hours. I > >> would like to design the app to use the table, RLOCK the row I'm > >> processing, and the UNLOCK the row when I'm done. I figure with this > >> design, I could run multiple instances of the MyProgram.exe (similar to > >> how WestWind Web Connection allows you to run multiple instances) to > >> process the batch maybe 4x faster (if I launched 4 instances of > >> MyProgram.exe). The basic construct would be as follows: > >> > >> USE ListOfRecsToProcess IN 0 SHARED Alias MyList && record is PK (to > >> process) i, tProcessed t, tError t, cSession c(10) > >> SCAN FOR EMPTY(cSession) AND RLOCK('MyList') > >> IF ProcessRecord(MyList.ID) THEN > >> REPLACE tProcessed WITH DATETIME(), cSession WITH > this.cSession > >> IN MyList > >> ELSE > >> REPLACE tError WITH DATETIME(), cSession WITH this.cSession IN > >> MyList > >> ENDIF > >> ENDSCAN > >> > >> > >> Does anybody see any problems with that general design? The > >> ProcessRecord method calls an API to get values and then updates the > >> local VFP record accordingly. > >> > >> tia, > >> --Mike > >> > >> > >> > >> -- > >> This email has been checked for viruses by Avast antivirus software. > >> https://www.avast.com/antivirus > >> > >> [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/cadj74tgp5n8j2jkakiskeedw8cuetaskfnekhy8ovddfzov...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
