Yeah, I remember I had that problem when I started out too. Good you solved it though. :)

Honestly, if you're going to add that many fields to a table, you're better off with a Recordset. SQL statements are better for short stuff. IMO.

Most of my experience come from web dev using PHP/MySQL so have always just built SQL statements. However, in this case, the "unsanitary" date gets pulled into an import table and the script I was working on in a first step "sanitizes" into a processing table before the next script breaks it down further into the normalized tables where it resides.. I'll probably eventually get to be a one step process but first just trying to get it right.

But I am using a recordset to pull the data from the import table... just still didn't think about creating a second rs to build the second process.. was just looping through creating the SQL statement then db.execute...

Thanks for the suggestion!

@Donald B. While you're at it, create a few functions that "convert/sanitize" strings, dates and numbers, so you have an easy call in the various rs!data routines you will do over time. I used to get a lot of weird formats from different systems in my old application. I just kept adding code to the function to deal with the new ones.

Hi Donald, I truly believe that we learn more through our mistakes than we do by not making them. I think of all the times in life when I said, "Wow, I'll never do that again!"  So, I learned a great deal and you learned a great deal about importing, exporting and SQL statements   John

Yeah, I'd say about 75% of my personal knowledge is from trial and error. LOL

Thanks everyone! I agree with each of you... Since I was still debugging the original script, I went ahead and changed from SQL statements to another recordset and came to another, IMO, valuable realization as well: Sometimes, too many comments can be just as bad as too few.

I know that the application I'm working on will evolve because I'm trying to get it running at bare minimum first* and then I can add features throughout its evolution. For that reason, I was commenting what each thing in the code was so I could remember when I come back to it. But there were so many comments, it was actually starting to make the code HARDER to read. By switching to the 2nd recordset for the insert and the table having better naming, I was able to eliminate a lot of comments because the code clearly speaks to what  it is, so thanks again Richard!!

Also, I completely agree. I learn a lot from all the classes (I'm through Developer 11 so far) and the Tech Help but just reading the posts in the forums is also invaluable as I've learned a lot from seeing the various suggestions to resolve other peoples' issues as well. That's actually why I started this post, figured maybe help someone avoid losing time on something so simple!

Thanks again everyone!!!

@Donald Often, especially in Access, there is more than one way to skin a cat. We may try two or more methods. One is bound to be better in a given situation. More often than not, the error part might be with a bug in Access, which requires us to choose a less-than-optimal path.

A big one I can think of is allowing a form to run twice so a user can work on two records at once. One maybe for a customer task at hand and another for an interrupting customer phone call. Microsoft created a turd-plated solution with "instancing". Juan Soto pushes it as genius, but in my testing, it flat out fails miserably. Especially compared to fifty-year-old technology in Unix and other db systems.

Thomas Gonder, I don't think instancing is turd-plated. It's not fantastic and it could be implemented better, but if you do it right it works well. I just covered it in Access Developer 47.

@ Richard one of the many problems is that Access corrupts variables in one Instance from another instance. Also, when you close a form, it will close the wrong instance. Microsoft failed to implement sandboxing between the variable tables (why I say turd-plating), a very serious error. I've done bug reports on it, no response from Microsoft.