First of all, "S1037" is a weird number, isn't it? 😉
Point being, really, if you want a unique number, then you have to store them somewhere, so you know what numbers are already taken. The first thing you need to decide, is where. Database? Text-file?
There are several pitfalls to watch out for. For example, the old but never-disappearing 'out-for-lunch';
User 1 gets a form displayed, telling him that he's got number S1038. The user starts filling the form out, and in the middle of it, he leaves for lunch. Your system has not registered S1038 as taken, since the form is not submitted yet.
The not-very-nice user 2 requests the form, and since S1038 is not taken, he gets this number as well. He writes evil javascript code that redirects to www.porn.com, and then he submits the form.
Meanwhile, user 1 told everyone else at lunch to check record S1038 at yoursite.com later on. Now, I suppose you get the point.
MySQL and all other databases worth mentioning (except dbm?) supports auto incrementing values. So when a user requests the form, reserve him a number and then send it to him (check if you actually reserved it as well). (This ofcourse may cause you a headache if the users don't submit the form, you reserve lots of IDs that will never be used).
Of course, if it's not important that the user sees his "entry number" in the form, the operation gets alot easier. Have him submit the form, and then check for the next free number, assign it (and output it to the user if you want). If you're going for a database, you can, in most cases, rely on its functionality for this. If, however, you go with text-files etc, make sure your locking mechanisms are good enough. Just sit down and think what would happen if 1500 users hit the submit button the exact same milisecond! (don't worry about server load, memory etc though😉
hope it helped.