авторНу так создайте тест, который будет открывать все клиентские формы
Проект большой, разрабатывается уже 6 лет. Написать функциональный тест который вызовет все формы не так то просто (я вообще думаю что это нереально) + его придется переписывать каждый раз когда добавляется еще одна форма.
Думал поначалу схитрить :) В настройках проекта можно все формы сделать автосоздаваемые. Но к сожалению от этой идеи пришлось отказаться по ряду технических причин.

Мыльников Дмитрий
Для форм, которые ещё не созданы, описание структуры формы и свойств всех компонентов лежит в ресурсах, которые прилинкованы к вашей программе. Но пытаться их оттдуа извлечь и проанализировать, это та ещё задачка.

Собственно у меня есть еще код приложения :) а делфи имеет некоторые механизмы для парса *.dfm файлов, которые описывают датасеты. Парсер "почти" удалось написать, проблема только с описанием объектов-наследников, которое размазано по нескольким модулям. Писал по этому поводу на делфи-форум http://sql.ru/forum/actualthread.aspx?tid=696262


Смысл в том чтобы выявить возможные ошибки в клиентской программе при изменении схемы БД. К примеру переименовали какое нибудь поле в схеме, необходимо проверить, не забыли ли это поле переименовать везде в датасетах на клиенте.
То есть, вы хотите сказать, что проект настолько большой и "крутой", что стоит это делать именно так? Прогнать обычный тест оператором уже не получается?
Не совсем понял, что имеется в виду под обычным тестом?

DexterI
Только при этом не стоит забывать, что вся эта процедура "проверки" может занимать весьма приличное время. Поэтому я бы не стал её делать при каждой загрузке программы, а сделал бы какую-нибудь специальную команду, по котороая данный тест бы запускался. Всё равное кроме собственно разработчиков это больше никому не интересно. Так вот пусть они его и запускают, а пользователям это совершенно ни к чему.

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


Что касается способов проверки правильности запросов, альтернативных попытке их все создать и открыть, то их не так уж много, можно сказать, что он один. Прочитать тем или иным образом текст SQ запросов, потом распарсить (то бишь сделать синтаксический разбор и разделить на составляющие их элементы и смысловые конструкции), а потом уже пытаться анализировать структуру получившуюся запроса. Правда, если вы самостоятельно решите эту задачу, то следующим вашим проектом должен быть собственный SQL сервер, не меньше. :)

Да нет, зная текст запроса его можно лекго проверить средствами СУБД. В частности в оракле (который мы используем) есть пакет dbms_sql который и реализует описанный вами парсер, и позволяет сделать синт. анализ запроса, не выполняя его. Скорей всего так и буду делать. Проблема в том, что есть еще переменные привязки, хотелось бы протестировать их правильное наличие в датасетах