Search results

Ahh --- if you mean the alternate syntax provided by @MajP, then yes - I tried that. It performed the same as what I had, and did not resolve the error... if that is what you meant.

Not exactly sure what you mean. My backslashes are in order... as it works for some tables and not others. So, I'm pretty sure this is not an all-or-nothing syntax thing - it is a hard-to-identify apparent randomness on when Access deems a table to have MV fields - or so the error message...

Hmmmmm... I'm pretty sure I do not have any Autonumber fields in these scenarios. I did set a field to be a key field, but I should be able to delete/add rows without THAT affecting it.

Indeed - the backslash has gotten me more than once. In this case, however, it works sometimes and not other times. Can't figure out why Access thinks some tables have MV fields - that don't.

Well - the code works on some tables and not others. I tried your alternate syntax with the same results. It seems to pick some tables to complain about, but not others.

So, I'm getting an error 3825 from Access while running an INSERT INTO query, and the error says "SELECT * cannot be used in an INSERT INTO query when the source or destination table contains a multi-valued field." This is quite strange since neither table has any multi-valued fields. I found...

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... ;-)