Skip to main content

I’m using API calls through Excel VBA to GET, POST, PATCH data tables linking several 3rd party platforms.



For purposes of explanation of my issue, assume the following basic data.



Table-1 contains (3) records, with Field-1 containing data “A”, “B”, “C” respectively.


I can make a List GET call and it retrieves all 3 records properly with correct values in Field-1.


I can make a record GET call for record (1) and it retrieves record (1) with correct Field-1 value of “A”



Now I PATCH record (1) with a new value in Field-1 with “X”.


In my Airtable web grid view instantly showing the updated value of “X”



If I make a list or record GET call again, it still shows record (1) with a Field value of “A” even though I’m looking at the grid view with correct data of “X”. The next day making the same call and I get the correct value of “X”, as if it sat in a cache till an evening update.



I can DELETE record 1 and I still get the same original GET results with record (1) and field-1 value of “A” even though it’s not even there. Again this condition corrects by the following day.



I never saw anything like this. Any Ideas? Thanks in advance.

Patching, then immediately getting afterwards, works fine for me. If you feel like it’s a problem on Airtable’s end (as opposed to a problem with Excel VBA or your API calls), you may want to reach out to Airtable Support at support@airtable.com. Let us know what they say!

Patching, then immediately getting afterwards, works fine for me. If you feel like it’s a problem on Airtable’s end (as opposed to a problem with Excel VBA or your API calls), you may want to reach out to Airtable Support at support@airtable.com. Let us know what they say!


Thanks, will do. I perform the same operations with API calls to our CMMS software and it works great both ways.



As a back story, I had the opposite issue with the CMMS calls. I could not patch a particular field in the table. No errors, confirmed success on the patch, but data was not updated. It was on their end and they corrected.



This time the patch works great, and the get processes the request, with no errors, and the reply payload is populated with the original field data…or even the original record after it’s been deleted.



Strange, but will let you know. Thanks!

Patching, then immediately getting afterwards, works fine for me. If you feel like it’s a problem on Airtable’s end (as opposed to a problem with Excel VBA or your API calls), you may want to reach out to Airtable Support at support@airtable.com. Let us know what they say!


Support was helpful.



Turns out that excel caches html data and that was the issue (only on airtable??). Here was the support fix found



The response from your URL is being cached somewhere in MSXML2.XMLHTTP60


Put a random parameter like a timestamp to the end of the URL


i.e.


sURL=“http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&t=201902022 00423”



I added the following code at the end of my HTML script to make sure I could never get a duplicate and seems to be working



& “&Rand=” & Format(Now(), “yyyymmddhhmmss”) & LTrim(Str(Rnd))



Since I may have some looped statements that perform a series of GET calls with a second, I added the random number to the date/time string that is only granular down to a second 🙂



Thanks for response.

Support was helpful.



Turns out that excel caches html data and that was the issue (only on airtable??). Here was the support fix found



The response from your URL is being cached somewhere in MSXML2.XMLHTTP60


Put a random parameter like a timestamp to the end of the URL


i.e.


sURL=“http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&t=201902022 00423”



I added the following code at the end of my HTML script to make sure I could never get a duplicate and seems to be working



& “&Rand=” & Format(Now(), “yyyymmddhhmmss”) & LTrim(Str(Rnd))



Since I may have some looped statements that perform a series of GET calls with a second, I added the random number to the date/time string that is only granular down to a second 🙂



Thanks for response.




While adding a phoney URL parameter typically works, there are two risks with this approach:





  1. The server decides that these unanticipated new parameters are nefarious and denies access altogether.


  2. The server decides that your requests are aggressive and ignores the unanticipated parameters.




The right way to do this is to use the pragma feature in HTTP.



myHeaders.append('pragma', 'no-cache');


myHeaders.append('cache-control', 'no-cache');

Reply


Terms & Conditions