TC10 Работа из толстого клиента с СУБД напрямую?

[asterixik 6]

Суть задачи в следующем, есть 2-ух звенный ТС10, хочется в нем сделать журнал регистрации документов (№п.п., Дата, Наименование, Вид документа, Автор...). Причем работать с журналом будут несколько десятков человек. То бишь самый простой вариант с каким-нибудь набором данных из электронной таблицы не очень подходит, так как велик человеческий фактор и вероятность ошибки. По-этому возникла идея сделать плагин приложение для TC в котором была бы табличка с журналом и поля для заполнения. Сама таблица физически будет хранится в той же БД что и таблицы данных TC. 

Отсюда и вопрос: работал ли кто-нибудь с СУБД напрямую из толстого клиента? Так как один вариант это прописать данные для соединения с СУБД где-нибудь в плагине или в преференциях, и порождать в плагине новое соединение с СУБД. Но, с другой стороны ведь есть же уже соединение по которым обменивается запросами сам ТС, почему бы не использовать его. Но как?

 

Я понимаю что можно декомпилировать модули ТС и разобраться как он там с базой общается, но этот путь займёт неопределенное количество времени, и возможно кем-то из форумчан уже был пройден, и они согласятся поделится опытом.

 

Может быть кто-то имеет предложить другой вариант решения задачи?

[koner 45]

Так как один вариант это прописать данные для соединения с СУБД где-нибудь в плагине или в преференциях, и порождать в плагине новое соединение с СУБД

Был такой опыт. 

Я понимаю что можно декомпилировать модули ТС и разобраться как он там с базой общается

Мне почему то кажется что декомпилировать придется в ассемблер. Насколько я помню там все корни ведут в dll, но  я могу ошибаться.

[asterixik 6]

Хотелось  бы ограничиться Java. То бишь, проще просто создавать в приложении отдельное соединение с СУБД и работать через него?

Изменено 27 мая 2016 пользователем asterixik

[koner 45]

не знаю как проще. В моем случае коллега делал soap-сервис который крутился на сервере и работал с СУБД, я уже обращался к этому сервису из плагина ТС.

[Krusty 194]

а чо на "айтемах" не сделать?

[NGM 267]

а чо на "айтемах" не сделать?

 

...и генератором отчетов вытаскивать нужные формы для печати.

Реализацию (в силу слабого знания матчасти репортгенератора) преставляю только теоретически, но, по крайней мере, выглядит логичнее плясок с бубном и кривым OCI.dll. 

[asterixik 6]

а чо на "айтемах" не сделать?

Такой вариант тоже рассматривался, но как-то быстро его отбросили, хотя... Сейчас ещё раз рассмотрим с коллегами.

 

А Вы как видите такую реализацию, в общих чертах?

...и генератором отчетов вытаскивать нужные формы для печати.

Реализацию (в силу слабого знания матчасти репортгенератора) преставляю только теоретически, но, по крайней мере, выглядит логичнее плясок с бубном и кривым OCI.dll. 

Печать не нужна.

Нужен просмотр на экране, создание записи без последующей возможности редактирования (только администратором) с одновременной генерацией сложного номера по определенным правилам

[koner 45]

Можно сделать pom объект описывающий одну запись.
Сделать айтем со свойством: массив этих пом объектов.
Или вместо айтема тоже pom, но еще с логическим свойством для блокировки (помему pom нельзя блокировать).

 

Ну и все, остальное все в плагине. Блокируем, генерим номер, записываем, разблокируем. 

 

[Krusty 194]

Документ - "айтем" + нужные вам атрибуты + код который будет генерировать сложный номер.

[asterixik 6]

koner, Krusty спасибо

 

У меня такие же мысли намыслились как у Krusty по поводу подхода к реализации были, так что буду реализовывать наверное через item-ы 

[lexx174 373]

Отсюда и вопрос: работал ли кто-нибудь с СУБД напрямую из толстого клиента?

работали но на чтение.

если коротко - это неверный подход и нерекомендуемый - именно писать напрямую в БД.это противоречит логике работы с TC.Хотя технически не запрещено.

Для решения множества задач есть разные интерфейсы - ITK, JAVA API, SOA а так же надо учитывать бизнес логику тимцентра и использовать возможности его модели данных. Она гибкая,объектно-ориентированная. Используйте объекты модели данных,создавайте свои классы и атрибуты и уже из них стройте свою конкретную модель для конкретной задачи, легче будет получать через API потом данные

писать напрямую в БД - это даже чревато,вам необходимо хорошо знать сруктуру таблиц БД, как реализована объекто-ориентированная модель данных тимцентра на уровне таблиц оракла,саму модель данных,бизнес логику работы,в итоге это куча времени и гемора на изучение у вас может уйти.

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

Изменено 27 мая 2016 пользователем lexx174

[koner 45]

это неверный подход и нерекомендуемый

Я так понимаю речь не о данных/таблицах тимцентра, а о своих отдельных таблицах.
В противном случае полностью с вами согласен. 

[asterixik 6]

Ещё раз посоветовался с коллегами, решили попробовать реализовать стандартными средствами, то бишь через кучу naming rules с счетчиками (коих будет около 100, так как журналов много), а сами "журналы" получать с помощью поиска. Ну и скорее всего придется сделать приложение которое будет отображать результаты поиска в виде приближенном к журналу из ГОСТа, так как пользователи которым нужен "журнальный" вид не очень дружат с ТС, им надо чтобы по нажатию одной кнопки был "журнал".

 

Да, речь не шла о редактировании таблиц используемых ТС, речь шла о размещении собственных таблиц в БД ТС и редактировании уже их.

[Krusty 194]

Ещё раз посоветовался с коллегами, решили попробовать реализовать стандартными средствами, то бишь через кучу naming rules с счетчиками (коих будет около 100, так как журналов много), а сами "журналы" получать с помощью поиска. Ну и скорее всего придется сделать приложение которое будет отображать результаты поиска в виде приближенном к журналу из ГОСТа, так как пользователи которым нужен "журнальный" вид не очень дружат с ТС, им надо чтобы по нажатию одной кнопки был "журнал".

 

Да, речь не шла о редактировании таблиц используемых ТС, речь шла о размещении собственных таблиц в БД ТС и редактировании уже их.

я бы сразу советовал вам кодить, нейминг рулы..... ну может их вам не хватить, хотя если у вас 11 то там появились..... smart number, вроде так

.... пишите сразу свой прекрасный кодификатор.

О! У сименса попросите - модель данных Архив, может там есть все то, что нужно вам.

[tuzik 5]

Отсюда и вопрос: работал ли кто-нибудь с СУБД напрямую из толстого клиента? Так как один вариант это прописать данные для соединения с СУБД где-нибудь в плагине или в преференциях, и порождать в плагине новое соединение с СУБД. Но, с другой стороны ведь есть же уже соединение по которым обменивается запросами сам ТС, почему бы не использовать его. Но как?

 

У нас есть такое, и это, вероятно, самый простой для реализации вариант. Читаете конекшн стринг откуда-нибудь и работаете с sql напрямую. Сам толстый клиент напрямую к БД не обращается, только через tcserver.

С другой стороны, это накладывает свои ограничения: при 4-звенке прямого доступа к БД может и не быть. Ну и выглядит такой подход, скажем так, непрофессионально. Поэтому есть у меня желание перенести работу с SQL на серверную часть. Может у кого-то есть пример как сделать свой сервис в тимцентре, который вызывает pl/sql процедуру?