dan wrote: > The MAX(id) didn't return anything,
Best check your data types, and syntax. Either ID is somehow a string value, or you are offering the wrong SQL syntax: mysql> describe test2; +---------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------+-------------+------+-----+---------+----------------+ | ID | int(11) | | PRI | NULL | auto_increment | | Name | varchar(50) | YES | | NULL | | | Phone | varchar(15) | YES | | NULL | | | Address | varchar(50) | YES | | NULL | | +---------+-------------+------+-----+---------+----------------+ 4 rows in set (0.00 sec) mysql> select max(ID) from test2; +---------+ | max(ID) | +---------+ | 5 | +---------+ 1 row in set (0.00 sec) Hint: *Never* test your SQL through a programming interface. Doing so increases exponentially the difficulty of debugging your program logic and your SQL. Use the most direc databaset access utility to test your SQL first [In MySQL, the mysql program; in MS Access, the SQL view of the query designer] to test the SQL. Only when you know the tested and proven SQL syntax that extracts the desired information, or effects the desired change, should you try running the SQL programmatically. By separating the SQL logic from the application logic, you can be greatly simplify your debugging of both. > i eventually settled for an idea posted > to > SELECT id FROM memodata ORDER BY id DESC > then take the first line value and ignore the rest. Ideally though i want > the last line with the highest id number. I know for a fact that another > INSERT won't happen before the SELECT because they happen immediately one > after the other. So you must have your database server all to yourself. In a production setting, you will have to contend with concurrency issues. > > FYI, i'm using MySQL and DBD::mysql if that's any more help. DBD::mysql should be used as a specialized interface for the DBI module. For most database programming, it should not make much difference which SQL-compliant enguine you use. That is one of the design goals of RDBMS/SQL standard. It helps if you stick with the SQL-compiant subset of any engine's functionality. Sure each engine has its quirks. Access, for instance, likes to put those silly brackets around table and column identifiers, which tends to ghetto-ize SQL saved by the Access engine in the MS slum. It'll even slime that stuff into code you enter directly without the brackets. My remedy is to copy working SQL from the SQL window into a text editor, and save it outside Access. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
