currently, the most nasty thing under my desk is one soiled sock and one soiled shoe...from spilling my coffee on my drive into work. X|

I've dealt with this one. dang what was it. it was an easy fix. Here it is: System.Data.OleDb.OleDbConnection("provider=Microsoft.Jet.OLEDB.4.0;" & _ "data source=" & result & ";Extended Properties='Excel 8.0;IMEX=1';") note the use of the extended properties and how they have single quotes. [edit] the above treats everything as a string, but does solve the null issue. I found the code from when I had to do a similar program a while back.

Any time I start a new project or a HUGE re-write, then I use a mind map. I like FreeMind. It's easy and free. The great part of a good mind map software is the ease at which you add nodes. If I recall, Freemind uses the INSERT key. This way, I can do a brain dump with very little thinking about trying to dump my stuff in the right place. INSERT for subnode and ENTER for new node in same branch. Anyway, I think it's great.

The second lends itself to replacing the values with a file string and thus more flexible strFileValue = "summer;winter;spring;fall;late fall;early spring;late birthday" 'comes from a configuration file or user settings, or whatever. dim strArray as string strArray = split(strFileValues, ";")

To bad you can't tell them... "I took it out behind the barn and shot it. Now I'm writing a brand spanking-new database."

Look at the bright side, the code was easy to understand.

Thou Shalt Know Thy Incoming Data.

vb front end, access back end...to clarify.

A few years back, I started a consulting engagement. We took over support of all client/server programs. Get this, it was a public utility and all internal databases were in Access. Anyway, there was a large complicated program written by a non-programmer. How bad was the code? Well, if there was more than one way to connect to a database, the "programmer" used each type. If there was more than one way to do ANYTHING, they used every method. Then, to top it off, whenever we would make a change in one section of the program (tons of SQL) then another part would break. Each time a bug would be raised, it would be a few hours for fixing, testing, and fixing the sections that should not have broke but did. We stopped answering our phones at 4pm because we wanted to go home at 5. Otherwise, we'd work into dinner time.

LOL - was each filed to hol the chapter of a book! LOL - oh the horror!

All VB6 programmers are not like that. I've done a ton of complicated stuff with vb6. it just that novices tend towards vb6 because of it's ease of learning factor.