Prefetch-Method crashes MS-Access

Hi there,

i discussed this topic with Jerry start of this year for a while.
Since you released a new stable version, i took the time to test that behaviour again.

Prefetch_Test_db.zip (308.7 KB)

Attached you can find an ms access database, that contains one form, together with a small shapefile containing tree-locations.
When opening the form, it creates a background tile-Layer from a locally running osm-tile-server (windows linux subsystem is really great), - but this can easiely be changed in Form_Load to a common osm-tile server -, reprojects the shapefile, creates a thematic map based on a field in the shapefile and displays the results.

The plan is, to give the user the opportunity to store the background tiles locally, to be able to copy it all to a Laptop with no internet connection. For this i implemented the Prefetch-Method to fill a local tile-cache with the tiles of all zoom-levels.

So open the database, open the form (- to see the messages of the callback-interface you need to open the integrated vbe and the immediate window) and then click the prefetch-button.

For me, this crashes ms access reliably.

I would be very happy to get this component running reliable in an ms access form.
In spring this year even clicking on the identify-button on the form and double-clicking one tree reliably crashed ms access, but this doesn’t seem to happen with this new version, good.

Any ideas and help is very welcome.
I’ve a customer who would even like to pay a developer to get it this component in a whole stable in ms access, just get in contact with me, if you’re interrested.

So have a nice weekend
and best regards

Stefan

Hello @jTati

I started to review this issue, and realize that I do not have the local tile directory. Is that very large? could you zip some of it and upload it?

Thanks,
Jerry.

Good Morning Jerry,

the sample database generates a sqlite database to store the tiles. For this particular sample with it’s very small shape-file, the database shouldn’t get beyond xx MB in size. In february i posted you the original shapefile, that was much larger, and there this sqlite db became 100 - 200 MB in Size, depending on when the crash occoured.
I actually cannot send you such a database, since that is the process that reliably crashes MS access, it just vanishes from screen.

But if there is anything i can provide to help getting this fixed, - will do.

Thank’s for looking into this
and
kind regards

Stefan

Hello Stefan.

Ok, well I’ve had some success.

So it looked to me (and I think you said this also) that this newest database (the Prefetch Test) relies on a local disk-based tile service, similar to what is created using your older database (MapWinGIS TilesTest). So I revived the earlier one (which fetches from OpenStreetMaps, levels 1 through 19), and I couldn’t get past around level 12 before it crashed . The prefetch does background processing (that I still need to investigate) that the Access environment can’t keep up with (and I don’t yet know why).

First I changed the OCX to only allow one thread at a time to do the read from OSM. Even with this, it couldn’t keep up. I then noticed that if I stepped through the Access code, and with a breakpoint at each iteration of the loop, I would stop and wait, to let the background processing catch-up, so-to-speak. With this method, I was able to process up to about level 17 before it crashed (trying to process thousands of tiles in the background). And when it crashes, it is usually in an MS Office dll (Mso10Win32Client.dll).

Although levels 18 and 19 were incomplete, I switched to the newer database (Prefetch) that reads from the disk tiles to load into sqlite. One thing I changed was to use a new feature of the OCX that allows local disk-based tiles as files (not a hosted service).

tlsTemp.Providers.Add 1030, "localWMST", "file:///C:\Temp\TilesTest\tiles\{zoom}\{x}\{y}.png", tkTileProjection.SphericalMercator, 1, 19

I set up to pre-fetch levels 16 down to 12. Even so, it was still crashing, but I was able to catch one of the errors, and it was in the StopFunction (called on every tile) during the bulk tile loading. So I (at least for now) set the StopFunction to Nothing so that it won’t get called. I still got an error, so I went in again put a breakpoint at every iteration of the prefetch loop in Access, and in this case, was able to get through every level. Here’s the result in your app.

I’m generally convinced that there is an issue with background threading or events in the MS Access world. But the full verdict is not yet in. At some point, may be able to catch the root culprit. Or it may be there is a need for a custom OCX to work more reliably with Access. As it is, I already maintain 2 different custom OCX’s, for a couple customers with various proprietary reasons. (one is for the Progress environment, which is a similar ‘interpretive’ environment like Access.

That’s all for now. We can talk more about where to go from here.

Regards,
Jerry.

Hello Jerry,

thanks for investing your time!

I also spend my afternoon yesterday playing around with the debugger and the current source code, and i had the same experiences: Crashes occoured in different ms access modules, be it vbe7.dll or msaccess.exe. From source-code side it always had to do with modules around Thread-Handling while loading tiles and the different events (callback / stopIF / TilesLoaded). The most common error was: “Invalid tile reference number”.
For my very basic understanding this looks as if something gets mixed up with the expected tile references in the asynchronous background loading. Your answer points into the same direction.
I also looked into the source code for tile handling and found nearly no comment or documentation in the code, so no chance for me as a C+±newbe to understand anything at all.

By the way:
The tile source i use is a local running tile-Server, so no file based access, it’s technically the same, as connecting to an osm tile server. The only difference is, that it might serve the tiles much faster. That might be the reason why choosing the build-in osm-tileserver as tile source, makes it run more stable, cause the tiles come in much slower.

I don’t know, if you see it that way also, but if this turns to come out to be a general problem with thread-handling in the ocx, and then a different branch of this project might not be the right approach, but I’m open to everything.

Have a nice day and best regards
Stefan

Hello Stefan.

Just to clarify, I don’t believe there are threading issues with the OCX. In fact, the change I made (to force single threaded loads of OSM tiles) was dumbing down the OCX, and reverting back to an earlier state that was considered a bug (see MWGIS-207).

I agree with your opening paragraphs, but believe it specifically has something to do with how MS Access affects the asynchronous background loading. We don’t see these things when running within compiled applications. So it may be that we may need to enforce more single-threading, synchronous behavior within the OCX. Right now (by default) it is compiled with the so-called “free threading” model, as opposed to the STA (single-threaded apartment) model. That will be one thing I can easily change to check out the behavior. But as we dig down, there may be other things as well.

It is unfortunate that there are many sections of the code with very few comments. As I go in to make fixes/changes/etc, I try to add comments to clarify intent.

I still want to track down that “Invalid tile reference number”, and that may give us more clues.

Regards,
Jerry.