Hmm, sounds like you need to employ some lazy db queries, instead of running a query twice (potentially).
Interesting though: in what sort of application/reasoning are you doing this? I can see what you're getting back (the id) but where is it being used that stops you from entering the information at the same time?
I love this "order number" stuff. I saw another post elsewhere on a different forum, looking suspiciously the same , asking how to perform exactly this. At which point we noted that an order DOESN'T become an order until the final button "checkout" or "processing payment" is pressed, at which point everything in your shopping basket then becomes an order, and gets assigned a number, and entered into all it's relevant tables.
Giving someone an order number before they've ordered seems a bit like nonsense...
However, if you're dealing with "quotes" that's slightly different, but I think should probably maintain the same path. What's the point in giving someone a quote number until they're formalised their quote. (i.e. logged out, saved as "quote"). Again, it doesn't get inserted into the table and given a number until it's completed.
I hate to think how many blank records get created using this methodology, but it makes me shudder to think I have to use ALLOW NULL on all my columns
Not a good idea .. Lots of "blank" records .. lots of unintended null fields yes .. but most importantly .,. any multi user system now can get spurious writes to the same ID.
A better solution is to create a separate capture table that you store a username, timestamp or session # in and then allow for the capture and fiddling. When you programatically decide that you have the correct data .. write it to that master table that has all the pack drill , checks and balances.. Housekeep the capture table regularly with deletes..