I think I’ve discovered the solution to this problem. The quick answer:
Go to config.asp and edit the MySQL connection string. Change OPTION=4 to OPTION=16387.
For a detailed explanation, which should be of interest to the developers and moderators, read on. Sorry this is so long, but I wanted to be sure to explain myself thoroughly. Keep in mind that this worked for me, your mileage may vary.
I just installed Snitz Forums version 3.4.05. I’m using it with MySQL 4.1, and MyODBC 3.51, all on a Windows 2000 server, running IIS5. I followed the setup instructions and everything went fine. When I went to view the forum page for the first time, I got the following error in the statistics section:

Type mismatch
/snitz/default.asp, line 923

I looked at the code, and noticed that the error was occurring during a comparison of integer values. I added the ‘cint’ function, and it fixed the problem. But, I then encountered the error again, and again and again at other points in the code on other pages. I looked deeper and found that the variable that was causing the error in the first instance (default.asp, line 923), ‘Member_Count’, was derived from a SELECT COUNT statement. A little more research revealed this:

http://dev.mysql.com/doc/mysql/en/count-error.html

The COUNT aggregate function in MySQL returns a BIGINT value. ADO doesn’t like BIGINTs, which I knew, so it converts the data to a string, which ultimately resulted in the ‘Type Mismatch’ error. Once I realized this, I examined the connection string used in config.asp. Sure enough, the OPTION= value wasn’t set correctly (based on my past experience). It came shipped set at ‘4’. I changed it to 16387 and all the ‘type mismatch’ errors went away! The values for the OPTION command can be found here:

http://www.dwam.net/mysql/asp_myodbc.asp

You’ll notice that option 16384 says “Change LONGLONG columns to INT columns, as some applications can't handle LONGLONG or BIGINT.” Add option 16384 with options 1 and 2 from the same list, (1+2+16384 = 16387) and you’ve specified to MyODBC the exceptions that it needs to consider when ADO is the client. If you read the page above carefully, the author states that as of MyODBC 3.51 you can use OPTION=3. I’ve found this to NOT be true, and that OPTION=16387 is still necessary, and works in EVERY case. It may be true that MyODBC now supports BIGINT, but ADO still does not.
I think this may solve a lot of problems people were having with Snitz Forums when using it with MySQL.
Thanks for reading, and good luck to all! <