Доброго всем дня!
Необходимо параметры функции записать в строку, а затем строку распарсить и выбрать оттуда все параметры (пишется провайдер между программами). Параметрами могут быть, как числа, дата и время, текст, так и массивы, ссылки и объекты.
Среда разработки - Delphi 7.
Какой лучше выбрать для этого разделитель? Точка с запятой, запятая, пробелы могут встретиться в тексте, ковычки - тоже не очень как-то.
Может кто-нибудь сталкивался с такой проблемой? Поделитесь, пожалуйста, опытом.
Спасибо!

"<!@#>" или "</!@#>" - вот и разделитель

И что он будет провайдить?

Сделай с размером !
Т.е. в начале идёт число, которое обозначает число байт данных для параметра которые нужно читать.

К примеру:

16 Я уехал в африку9 Синий кот7 Тетрадь

Ой не спроста все это

велосипедисты... чем XML не угодил?

Kmet Дык, я спросил про "кухню", в подполье ушли ....

Согласен с Kmet - xml самый лучший вариант. Но если все же идти путем разделителя, то самый надежный вариант, применяемый во многих протоколах - это любой символ. Если он встречается в тексте, то удваивается. При парсинге строки пара этих символа преобразуются в один и относятся к тексту, оставшийся к разделителю.

Спасибо большое за ответы. Получается, что одни из лучших - это xml и удвоение символа. А если будут еще передаваться и бинарные данные в строку, то какой из этих лучше использовать?
Сама понимаю, что от велосипедов не деться. Суть такая, что из дельфовой программы нужно передать в хранимую процедуру СУБД (dll) входные параметры. А так как количество входных параметров может быть разным для разных функций, то было принято решение занести все параметры в один. Если у вас есть лучшее решение и пр., то буду рада любой критике

И еще вопрос: какие существуют классы, методы, объекты, чтобы парсить и формировать xml? С этим еще не сталкивалась я. Буду рада помощи.
Спасибо!

Вот тут надо поконкретнее ... у вас ХП в длл? или что? Да и саму СУБД неплохобы указать.

СУБД - Advantage SQL.
Да, создали одну ХП в длл для универсальности. Эта процедура обрабатывает один входной параметр, разбивает его на массив параметров и передает уже эти параметры нужной внутренней хранимой процедуре СУБД (Advantage SQL). Поэтому и была написана одна универсальная хранимая процедура (ДЛЛ), которая смогла бы обрабатывать множество других процедур и функций, чтобы не клепать множество идентичных самописных длл. Поэтому и было принято решение все параметры засунуть в один. Это легче при интеграции, масштабировании, развертывании и по производительности.
Что скажете?
Есть вариант формирования строки по схеме - длина 1 параметра - первый параметр - длина 2 параметра - второй параметр и т.д. Такой подход мне кажется производительным - только один цикл для строки. Для удвоения - нужно будет несколько циклов, и для xml тоже будет трудоемкий процесс.
Или может еще что-то. Как вы считаете?

Что-то не совсем понимаю, зачем все эти выкрутасы .... и не понимаю при вашем (хотя он уже и не совсем ваш, в инете много ваших вопросов по форумам) варианте, как узнавать будете что 1 параметр к примеру не 3-ий и не 5-ый? В идеале надо бы еще знать что есть что. А если у вас это все строго определено, то нафик все эти движения с "универсальностью", если в итоге никакой универсальности нет? Или я чегото не допонимаю, или ... ну впрочем помошников у вас много ...

что вы понимаете под длл?


багадром... не очевидно как передавать числа, даты и тд


имхо, идеальный вариант если не надо сохронять информацию о типе.

согласен с sax_ol, непонятно какие мотивы вас сподвигли на такое неоднозное решение. БД с множеством ХП, которые обеспечат проверку типов, много лучше вашего решения.

Мотивы такие оказались из сложности самой платформы, на котором все работает уже много-много лет. А вот сейчас хочется это все переместить на новый движок на новую СУБД с совместимостью с прошлыми наработками. Другие варианты, как не рассматривали - не подошли. А из-за того что я только часть проекта осветила, а 95% - нет, вот и появляется уверенность, что это очередной велосипед и багадром...
Вы правы, как никогда Без этого ни одни проект не создается.
>не очевидно как передавать числа, даты и тд
Как строку. Есть же функции для преобразования типов. С этим как раз проблем не будет.
И БД с множеством ХП как раз и будет. И мой провайдер тоже будет использоваться для конкретных задач.
Спасибо большое всем за отклик!

уверенность осталась

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