Recent content by Papa_Bear1

Interesting... I'm experimenting with PowerShell at the moment. I've barely done anything with it, so my first attempts, although working with small files, are abysmal with the big files - just too slow. It seems to be very difficult to just pull data into anything other than a single...

The files contain X-Y-Z data from a geotif file, space-delimited with Longitude Latitude Elevation data, and I'm only retrieving the elevation data, and by placing the data into an array in the proper position, I need not store the Lat/Lon. Parsing that 3rd column out was another little...

I see - I wasn't really aware of when/where the cleanup occurred for the recordset, and certainly was not aware of the multiple pieces to it internally. There is always more going on under the hood than I'm imagining (especially in THIS world... :) ) As far as the rows/columns thing - in this...

Well - in this particular instance - I'm having to process a very large amount of information, and every time I try to use tables - it either gets too big for Access to handle, or gets too slow. I generally err on the side of storing data in tables (probably to a fault actually...), but in this...

OK - so @The_Doc_Man is spot on... again... While experimenting with the file order (per @DHookom), I found that if I simply repeated ONLY the TransferText command for different files, it was fine. It progressed beyond the 3rd file etc. But when I included defining my recordset after each...

Good idea. I do think I have a handle on what is happening where and when - so I've not tried to include any feedback like this just yet. (I've found this kind of feedback to be absolutely VITAL when doing recursion - including how many 'layers' in I am etc. - that's for sure!!)

That's a great troubleshooting idea. In my current context, the order is rather controlled (walking an array of files that organized positionally, so I'd have to throw a monkey wrench into that to test this idea. If/when I can do that - I'll follow up.

Good ideas... I did initially put a breakpoint on the TransferText command, as you might expect, but I did not yet try omitting some of the other steps - (like reading in the data etc.), which I'll try next. The only variation in what happens, though, is whether I skip doing anything with the...

OK - tried this on a non-corporate-managed computer - and it does the same thing. I admit I'm quite surprised. Either the other computer has something similarly configured - or this is an actual bug of some kind (whether my code or Access). If I can find time, I'll try to whip up a simple DB...

Got it.

It is the TransferText command. I can indeed display the spec - in the system table, at any time. It exists before, during, and after the code runs.

I understand the general principle of supplying code - but in this case, I just can't see how that matters much. I did describe what I'm doing - using TransferText, with an import spec, inside a loop, that works three times in a loop and then suddenly doesn't. Interesting point on the file size...

I did look at the MSysIMEXSpecs, and it is there. In fact, if I were to restart the system and run it again - it seems it gets through three iterations - using that spec successfully, and then fails. So, it very likely isn't about the spec existing or being referenced properly etc.

In this case - no - I don't have any Resume Next stuff happening, and also no SetWarnings False either (as far as I know... ;-)

Indeed - I will try that today!