Т.е. у тебя стоит задача автоматической генерации нового шифра заказа?

Ну, для начала, надо бы узнать, есть ли какие-то формальные условия для шифра заказа. Подойдет ли простой порядковый номер или нужно что-то еще.

В общем случае, шифр может выглядеть следующим образом:

Префикс - порядковый номер - окончание

Префикс и окночание - это некоторая постоянная цифро-буквенная часть. Постоянная в том смысле, что меняется относительно редко. Например, раз в год.

Если задача может быть формализована именно таким способом, то нужна дополнительная служебная таблица, хранящая последний использованный (или первый НЕ использованный) порядковый номер. Выцарапывать его из уже готового шифра - достаточно сложная задача.

В такой постановке, просто берешь очередное значение из этой служебной таблицы, добавляешь префикс и окончание и проверяешь шифр на уникальность . Если получился НЕ уникальный номер, то берешь следующее значение. И так до тех пор, пока не получиться уникальный номер.

Использовать значение порядкового номера удаленных шифров не надо. Почему? Объяснять долго. Просто поверь на слово. Оно того не стоит.

Для значения префикса и окончания также надо создать дополнительную служебную табличку (или дополнительные поля в той таблице, где храниться порядковый номер). Это позволит сохранить историю изменений шифра, когда понадобиться ввести шифр задним числом.

Делать шифр в виде краткого обозначения содержимого (то, что предложил kdanylo ) мне не кажется хорошей идеей. А если изменился справочник? Модифицировать все старые заказы? А если изменилось содержимое заказа? Опять менять шифр? А если в одном заказе несколько автомобилей?

Кроме того, это стереотип DOS-программирования, когда экономили каждый байт и пытались навесить несколько функций на одно и то же поле. В данном случе шифр заказа выполняет 2 противоречивые функции: идентификации заказа и анализ содержимого заказа. Это не есть хорошо. Точнее - очень плохо! Часть связанных именно с этим проблем я привел выше.