В одном из проектов было выбрано проектное решение дополнить прикладную систему аналитическим приложением. Нужно было показывать кросстаблицы. Был выбран Контур-Стандарт. Причины выбора, как я уже сказал, были проектные, а не технические. В Cache данные хранились специфическим образом, никак не в виде SQL таблиц, клиентское приложение понимает только SQL, так что стояла задача скрестить ужа с ежом.
Покрутив, повертев КС (Контур-Стандарт), пришел к выводу что программа вполне добротная, честно заточена на абстрактные данные и собственно сам OLAP выполняет на клиенте. Получает сырую табличную выборку и самостоятельно проводит OLAP операции. Это уже вселяло надежду. Какую? Да простую - на сервере не придется хотя бы с самими OLAP операциями код городить.
Вторая надежда на успех появилась после того, как выяснилось что КС может брать данные через ODBC. ODBC к Cache настроить не вопрос.
Третья надежда появилась когда в списке вариантов получения данных кроме собственно SQL таблиц отыскалась возможность вызывать хранимую процедуру. Вот за это хочу сказать спасибо разработчикам КС, без этого пришлось бы городить код синхронизации данных в параллельное хранение в виде таблиц.
Подводные камни в виде подводных каменных граблей стукнули по голове когда объявил на сервере хранимую процедуру которую можно вызвать через ODBC и обратился к ней из КС. Сервер ответил что не поддерживает обращение в виде
Да, есть такое расхождение в SQL серверах - допускается писать и execute и call. Изучение опций КС показало, что не получится указать какой из вариантов надо использовать.
Поэтому решение в стиле администраторов (что-то где-то настроить) не прокатывало, как и решение в стиле программистов (что-то где-то на чем-то написать). Оставалось решение в стиле хакеров - что-то где-то изменить.
Я сделал копию исполняемого файла КС и проверил что он корректно запускается и работает если имя файла изменено. После этого в копии обычным редактором FAR, который полностью сохраняет все символы кроме измененных и не заменяет переводы строк автоматически, то есть дает редактировать бинарные файлы, поискал вхождение в файл строк execute. Такие нашлись. Те вхождения, которые содержали после execute символ форматирования %s, я трактовал как заготовку формирования запроса к хранимой процедуре. И поменял символы execute на call с затиранием оставшихся пробелами. В языке SQL в отличие от языка M количество пробелов значения не имеет. Решение получилось потому, что строка call короче, чем execute.
После этого КС заработал уже как надо было для Cache, и стал отправлять серверу корректный для него запрос вида
Покрутив, повертев КС (Контур-Стандарт), пришел к выводу что программа вполне добротная, честно заточена на абстрактные данные и собственно сам OLAP выполняет на клиенте. Получает сырую табличную выборку и самостоятельно проводит OLAP операции. Это уже вселяло надежду. Какую? Да простую - на сервере не придется хотя бы с самими OLAP операциями код городить.
Вторая надежда на успех появилась после того, как выяснилось что КС может брать данные через ODBC. ODBC к Cache настроить не вопрос.
Третья надежда появилась когда в списке вариантов получения данных кроме собственно SQL таблиц отыскалась возможность вызывать хранимую процедуру. Вот за это хочу сказать спасибо разработчикам КС, без этого пришлось бы городить код синхронизации данных в параллельное хранение в виде таблиц.
Подводные камни в виде подводных каменных граблей стукнули по голове когда объявил на сервере хранимую процедуру которую можно вызвать через ODBC и обратился к ней из КС. Сервер ответил что не поддерживает обращение в виде
execute ProcedureName(Params)На допросе документация Cache показала, что нужно писать
call ProcedureName(Params)Но КС был разработан, видимо, программистами, оперирующими документацией от Microsoft, в которой они честно писали что их сервер поддерживает именно execute. Но это их сервер, MSSQL. А тут Cache.
Да, есть такое расхождение в SQL серверах - допускается писать и execute и call. Изучение опций КС показало, что не получится указать какой из вариантов надо использовать.
Поэтому решение в стиле администраторов (что-то где-то настроить) не прокатывало, как и решение в стиле программистов (что-то где-то на чем-то написать). Оставалось решение в стиле хакеров - что-то где-то изменить.
Я сделал копию исполняемого файла КС и проверил что он корректно запускается и работает если имя файла изменено. После этого в копии обычным редактором FAR, который полностью сохраняет все символы кроме измененных и не заменяет переводы строк автоматически, то есть дает редактировать бинарные файлы, поискал вхождение в файл строк execute. Такие нашлись. Те вхождения, которые содержали после execute символ форматирования %s, я трактовал как заготовку формирования запроса к хранимой процедуре. И поменял символы execute на call с затиранием оставшихся пробелами. В языке SQL в отличие от языка M количество пробелов значения не имеет. Решение получилось потому, что строка call короче, чем execute.
После этого КС заработал уже как надо было для Cache, и стал отправлять серверу корректный для него запрос вида
call ProcedureName(Params)В результате решением оказалось состоящим в использовании указанной хранимой процедуры на сервере и такого вот измененного исполняемого файла КС. Оригинальный файл можно было оставить, хотя он в том проекте и не использовался. После инсталляции КС на другом компьютере на него надо было скопировать измененный exe, если ставился КС той же версии, либо, поставив другую версию, снова провести ее адаптацию.
Комментариев нет:
Отправить комментарий