Search results

Indeed!!! Ha!! :unsure:

Right - totally get it - in general. I just so happen to not be able to upload sample code easily. I'd have to spend more time than I have creating something I can/should/be allowed to upload - and then - it probably wouldn't end up looking close enough to the original to be worth inspecting...

True ---- In this case, I've described the problem. From what I can see here, the names of tables and fields is irrelevant - right? The problem is that the same query that works on *some* tables, suddenly doesn't work on others, and exhibits an error that is completely erroneous - talking about...

Just an FYI --- I tried running the same type of query on the two databases again, manually, with both of them open --- and now it magically works. This has me thinking that it may be a permissions issue of some kind, perhaps with an erroneous error message. It seems that if I create the DB...

I did a scan of that - comparing the fields in both tables, and they all looked the same. I actually created the external destination table using a query from an empty version of the source - so unless my empty version is somehow mismatched (which has definitely happened when I change a table...

In this case - No. The tables are relatively "normal". :)

OK - good to know. I vaguely recall being able to insert rows into a table with Autonumber, (including values for that field) but I also recall that things kind of got wonky sometimes - so my approach since then has been to either use Autonumber - and let it do what it wants, or don't use it...

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.