Schema error with mysql

Subscribing

I have the same mismatch, is this a problem? what is the fix?

Actually I'm not sure what this means. I know what it says, but who cares, so it's 'not null' why is that a problem. If I go into phpmyadmin and hit the null checkbox, it won't save it.

The same for me ....

blogapi_files
o column fid - difference on: not null
declared: array('description' => t('TODO: please describe this field!'), 'type' => 'serial')
actual: array('description' => t('TODO: please describe this field!'), 'type' => 'serial', 'not null' => TRUE)

Yep, same; first error on a clean install, after repairing for over a week and had it all nice back again.

But after the mess that had happened, any database error is unacceptable and needs to be resolved first, before new modules or upgrading any module, in order not to return in the ultimate chaos I was in and very near loosing my webhost account. So should this module be deleted so I can continue Drupal, until in some time there comes a message that the database problem with this module has been resolved?

what is the difference between "declared" and "actual"; there might lay the answer..:

What is difference between a formal and an actual parameter?
The variables declared in the procedure and which are passed, as arguments are called actual, the parameters in the procedure declaration. Actual parameters contain the values that are passed to a procedure and receive results. Formal parameters are the placeholders for the values of actual parameters

=> ?

Hey, but here is a nice video explaining a lot:
http://www.lullabot.com/videos/database-fun-schema-module

So 'something' has changed the original declared value. So now the question is was this what the programmers wanted and used a bad way of programming? Or is this an error by definition and should be brought back in the original state?

The video explains how to repair... but be careful for a life-site and with a lot of valuable data, back up the database and the individual tables and maybe also write down exactly what the changes are (in order to be able to manually change it back).

=> I cant change it back from INT to SERIAL with NULL or 0; seems not to work on the version of MySQL server:

Error
SQL query:
ALTER TABLE `micrblogapi_files` CHANGE `fid` `fid` SERIAL( 11 ) NULL
MySQL said: Documentation
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(11) NULL' at line 1

Thought I have a recent version that suits Drupal...: "MySQL version 5.1.46-log"

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(11) NULL' at line 1

=>

Error: 1064 SQLSTATE: 42000 (ER_PARSE_ERROR)
Message: %s near '%s' at line %d

???

But finally I think I found here the answer: http://www.ijs.si/software/amavisd/README.sql-mysql.txt

SERIAL can be used instead of INT UNSIGNED NOT NULL AUTO_INCREMENT with databases which do not recognize AUTO_INCREMENT; The attribute SERIAL was introduced with MySQL 4.1.0, but it implicitly creates an additional UNIQUE index, which is redundant.

So maybe that INT + auto-increment is the favorable method and automatically changed on some servers?