📄 access.comment
字号:
Access 97 tested through ODBC 1998.04.19, by monty@mysql.comAccess 97 has a bug when on executes a SELECT follwed very fast with aDROP TABLE or a DROP INDEX command:[Microsoft][ODBC Microsoft Access 97 Driver] The database engine couldn't lock table 'crash_q' because it's already in use by another person or process. (SQL-S1000)(DBD: st_execute/SQLExecute err=-1)Debugging SQL queries in Access 97 is terrible because most error messagesare of type:Error: [Microsoft][ODBC Microsoft Access 97 Driver] Syntax error in CREATE TABLE statement. (SQL-37000)(DBD: st_prepare/SQLPrepare err=-1)Which doesn't tell a thing!--------------Access 2000 tested through ODBC 2000.01.02, by monty@mysql.comcrash-me takes a LONG time to run under Access 2000.The '1+NULL' and the 'OR and AND in WHERE' tests killsActivestate Perl, build 521, DBI-DBC with an OUT OF MEMORY error. The later test also kills perl/access with some internal errors.To go around this one must run crash-me repeatedly with the --restart option.Testing of the 'constant string size' (< 500K) takes a LOT of memoryin Access (at least 250M on My computer).Testing of number of 'simple expressions' takes REALLY a lot of timeand memory; At some point I was up to 350M of used memory!To fix the above, I modified crash-me to have lower max limits in theabove tests.Benchmarks (under Win98):Running the connect-test will take up all available memory and thiswill not be freed even after quitting perl! There is probably somebug in the Access connect code that eats memory!
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -