API design question for a recordset class

I’ve developed a database, a recordset, and a database field class with the same API as the built-in ones. The goal is to implement an asynchronous way of loading the rows for MySQL and PostgreSQL. It is all done within Xojo with declares around the C APIs.

I started with MySQL and first implemented the synchronous way with mysql_store_result (the way Xojo works), and then switched to the asynchronous way by using mysql_use_result within a Thread.

Everything works fine, with - of course - one exception. When looping over the records like that:

Do Until rst.EOF // do something with the current record rst.MoveNext() Loop
… it can happen, that the next record has not yet been consumed by mysql_use_result. This of course will only be the case on a very very slow database access, and I mean veeery slow - but it can happen (thanks to Bob Keeney for his blog about the Network Link Conditioner which helps me test this).

Should I try to block MoveNext internally until the next row has been added by the thread loading the data from the database? Or should I change the API of my recordset class (which at the moment has its API identical to the Xojo one)? For example I could introduce events, like LoadProgress(countOfLoadedRecordsByNow As Integer). Or should I get away from MoveNext etc. and give the class a more array-like API (something along ValueAt(row, column) and LoadedRecords() As Integer)? Or is there a better way to solve this?

As stated in the title, this is purely an API design question, not a technical one.

I would expect move next to wait…

Having used an async API for a database I can say that you REALLY have to twist your head to write something simple like a client server app that just loads a bunch of rows into a list.
Not that it can’t be done, and you can actually do progress fairly readily, its just harder to get your head around because it’s all async.

High latency networks do pose other issues BUT you’re going to have to deal with that anyways now because you can’t make your API run in a separate preemptive thread (which the updated Xojo plugins do) so if a call to the underlying DLL/dylib blocks you won’t have any way to deal with it