I'm not going to address these comments to anyone - in an attempt to avoid inter-personal conflict...
Herewith some psychology and philosophy: - some people can't be bothered to read the manual - writing a (good/complete) manual is even harder than reading it - fully appreciating each fine detail as you read it amidst a myriad of ifs, buts, and maybes, in some language feature/function's technical description can be challenging - some people find it easier to ask others than to read/work it out for themselves - some people think others are paid to be on the list to answer questions - some people seem to think they will 'break' the computer/MySQL if they 'experiment' - some people think that if they don't know/can't read something, asking others is preferable to/quicker than experimentation - some people think they know the answer to list questions and dash off a response without checking the manual/really understanding the question/really knowing the answer - the person who has provided the most consistently correct information in this thread has been most criticised - the people who provided incorrect/out-of-date information/advice have yet to be castigated - would you put incorrect advice on a par with Microsoft marketing blurb? (and you know how techies like to rage against that!) - technical manuals tend to lay out the facts "this is how it works", and any rules/exceptions - technical manuals do not tend to get into the design philosophy behind the code that implements the commands/makes it all work - many users find discussion of such philosophy 'incidental' and ask for the 'short version' Why did the original post-er ask the question? Almost certainly because (s)he has read the manual where it says that there is no native support for referential integrity in MySQL, and needs to set up a relationship between two rows in different tables using a column that has its value set by AUTO_INCREMENT. I first learned SQL as pure theory - before the standard was implemented. The earliest versions/implementations, eg early DB2 and ORACLE, did not include native referential integrity, it was something we were taught to code for ourselves. I'm fairly sure that the prevailing wisdom (now we're straying into the area of transaction-processing) was that you worked out what the 'primary record' would be, and then coded up the dependent record (including its foreign key) and stored it, and finally stored the 'primary' record. IIRC and if there are other (non-MySQL) implementations that follow that same approach, then this explains why so many people ask the question "what will be the NEXT key to be used by AUTO_INCREMENT". Unfortunately respondents trying to tackle that question literally, disappear quickly into transactional processing. However MySQL offers a range of functions to 'display' AUTO_INCREMENT values, and report back on recent activity. More so when you include interfacing languages' functions, eg PHP or Perl; and many of these occur automatically as a result/by-product of an earlier call to MySQL (rather than requiring a second/separate/additional call to be made across the interface). NB this feature/characteristic nullifies some of the other comments made during this thread. What should be understood is that MySQL's implementation of AUTO_INCREMENT requires a particular/different philosophical view: that first the 'primary row' is to be stored, then the AUTO_INCREMENT data captured, and finally the dependent row is stored (in the second table) - a reversal of the earlier-mentioned approach. As soon as one understands how the whole job is to be done, the logic of the individual components becomes 'obvious'. (and the old dog has to remember his new tricks!) Did I miss anything/get any part wrong? Regards, =dn --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
