Описание текущего состояния разработки

Примерное направление для улучшения:

Способы работы с данными

Необходимый функционал классов:

Требуются ваши мнения по следующим вопросам:

Резюме

samonon
Требуются ваши мнения по следующим вопросам

samonon
Здравствуйте, предлагаю к обсуждению большую тему

samonon
1) Внедрение единого подхода к работе с данными, независимо от источника (dbf или серверная база данных)

samonon
2) Внедрение современных методов работы с даными

samonon
4) Написание кода, который можно было бы впоследствие перенести на другие платформы - (отказ от навигации по dbf таблицам и др).

samonon
- формы не включаются в exe, так как часто требуется что-то изменить на скорую руку, а общий файлов достигает 100мб.

samonon
- большинство таблиц не имеют суррогатных ключей.

samonon
- нет администратора баз данных DB2

samonon
- таблицы в DB2 создаются программистами под едиными админским паролем в одной схеме. Этот же пароль потом иногда используется в приложении.

samonon
- обновление таблиц делается с помощью TABLEUPDATE() на специальный курсор (remote view), созданный с помощью SQLEXEC и настроенными параметрами SendUpdates, UpdateNameList, etc.... - опять без проверки результата TABLEUPDATE().

samonon
- хранимые процедру не используются.

samonon
6) Использование ADO - нет!.

samonon
- использовать только SQL команды для работы с DBF таблицей, не использовать DBASE команды, зависяще от текущей записи.

samonon
- добавить первичные ключи, там где их нет, для удобства работы SQL.

samonon
- в дальнейшем отказаться от использования нативного доступа к таблицам и взамен использовать доступ по ODBC/ADO.

samonon
- в дальнейшем отказ от использования таблиц FoxPro и перенос их на сервер

samonon
2) Писать новый код/переписывать старый код для удобства переноса на платформу 1С
- доступ ко всем таблицам с помощью из 1С через ADO/ODBC

samonon
1) Нативный доступ к DBF таблицам - не рассматриваю, как устаревший формат хранения для приложений корпоративного уровня

samonon
протокол ODBC

samonon
CursorAdapter (VFP 8+)

samonon
CAD - может быть добавлен визуально только в DataEnvironment.

samonon
4) ADO - основная проблема, что в нашем приложении ADO раньше не использовалось - будет сложно приучить людей к нему.

samonon
нет смысла заморачиваться разработкой чего-то нового на устаревшей платформе. Лучше сделать минимальные набор классов для самых распространённых вариантов использования и успокоиться на этом.

samonon
1) Основная технология доступа к данным ODBC (SQL passthrough + CursorAdapter)

samonon
- доступ к dbf таблицам можно также организовать через драйверы

samonon
1) Основная технология доступа к данным
ODBC (SQL passthrough + CursorAdapter ) или OLE DB (ADODB.* + CursorAdapter)
- ODBC используется на данный момент, имеет достаточную функциональность

PaulWist
- При select нельзя получить несколько курсоров.

PaulWist
- Обновление источника данных происходит "позаписно" (сильно аукается, когда на табличку навешаны триггеры)

PaulWist
- Нельзя получить с сервера курсор с необходимой схемой

PaulWist
- "новые" типы данных не поддерживаются (n/varchar(max), XML и др.)

PaulWist
- Сохранение/модификация c помощью SPT.

Igor Korolyov

PaulWist
- При select нельзя получить несколько курсоров.

В контексте одного обращения к БД (скажем одного вызова ХП)... А насколько это актуально?
Т.е. чем плохо сделать 2-3 или сколько надо CAD с отдельными запросами/вызовами?

Igor Korolyov

PaulWist
- Обновление источника данных происходит "позаписно" (сильно аукается, когда на табличку навешаны триггеры)

Так 99% работы с данными и происходит "позаписно". Массовые операции - сравнительно нечастая штука, и как раз таки их и имеет смысл изолировать в ХП на сервере (если они не сверх-гибкие, т.е. заранее неизвестно чего как надо обновлять/создавать - только из кода клиента можно создать соответствующие команды).

Igor Korolyov

PaulWist
- Нельзя получить с сервера курсор с необходимой схемой

Опять же а какова цель? IMHO крайне вредно когда структура курсора заметно отличается от результата запроса, и происходит то или иное неявное преобразование. Конечно, есть исключения, скажем datetime "урезать" до date (если вдруг серверный date всё равно через odbc придёт как datetime, или на сервере в принципе нет типа date, а бизнес-логика не нуждается во "времени"), да и ошибки/особенности в реализации ODBC драйверов таки бывают (когда вместо double(5) зачем-то в фокс приходит какой-нить неадекватный number(10,0))... Т.е. оно и полезно, но оно же и опасно - сколько ошибок допущено именно из-за несоответствия схемы реальному результату запроса... И ведь не все они сразу видны, т.е. формально "ошибки" и не возникает - возникает странное поведение, потеря данных...

PaulWist
- "новые" типы данных не поддерживаются (n/varchar(max), XML и др.)

А оно нужно для "старой" системы? Да и для новой вполне можно обойтись и без "хитрых типов" - они таки сильно неуниверсальны. Вот в том же db2 (и оракле, кстати) никаких varchar(max) нет и в помине

Igor Korolyov
Для типичной работы оператора со вводом данных в гриды/формы, это (вынимать через CAD, а сохранять через SPT) будет совершенно неэффективно и избыточно.

PaulWist
1. Это ограничение СА.

PaulWist
2. Для многодетальных отчетов очень актуально,... согласен, что таких отчетов немного, но они есть.

PaulWist
3. Не всегда возможно получить доступ к объектам, например к тем, которые выполняются от другого контекста олицетворения.

PaulWist
Да ладно Мастер - Детали.

PaulWist
Ну и классика жанра, row-level вызов триггеров тождественно равная кол-ву записей в деталях, вместо одного вызова над набором модифицируемых данных.

PaulWist
Конечно нужно, все типы max можно получить только через СА

PaulWist
в предложенном случае будет хоть какое-то однообразие доступа и модификации данных, да с использованием "двух" технологий, но во всяком случае не надо будет вспоминать "где играли, а где рыбу заворачивали"

Igor Korolyov

PaulWist
1. Это ограничение СА.

Это его логика.

Igor Korolyov

PaulWist
2. Для многодетальных отчетов очень актуально,... согласен, что таких отчетов немного, но они есть.

В чём проблема сделать 2-3 или сколько надо отдельных запросов, отдельных CAD объектов?

PaulWist
3. Не всегда возможно получить доступ к объектам, например к тем, которые выполняются от другого контекста олицетворения.

Понятия не имею про что эти слова.
Но все требуемые CAD вполне могут (да и обычно должны) работать через одно соединение. Как там может быть разным хоть что-либо между 2-мя последовательными запросами, тем более SELECT-ами ничего в БД и в сессии не меняющими - для меня загадка.

use tempdb 
go

create table dbo.t(id int)
go

-- ХП заносит одну запись и вынимает двойку
create proc dbo.sp_t1 
@id int
as
insert into dbo.t values(@id)
select 2 as ID from dbo.t
go

-- ХП выполняет ХП sp_t1 и вынимает записи из dbo.t
create proc dbo.sp_t 
@id int
as
exec dbo.sp_t1 @id
select * from dbo.t
go

-- Создаём юзера БД u1
create user u1 without login
go
-- Права на exec dbo.sp_t для u1
grant execute on dbo.sp_t to u1
go
-- Создаём юзера БД u2
create user u2 without login
go
-- Права на exec dbo.sp_t1 для u2
grant execute on dbo.sp_t1 to u2
go
--*********************************
-- Выполняем dbo.sp_t1 от юзера u2
-- Переключаем контекст выполнения путём олицетворения другого юзера
exec (N'dbo.sp_t1 1') as user = 'u2'
/*
(строк обработано: 1)
-----------
2
(строк обработано: 1)
*/

-- Переключаем контекст выполнения на u1
execute as user = 'u1'
-- Выполняем dbo.sp_t от юзера u1
exec dbo.sp_t  1

/*
(строк обработано: 1)
-----------
2
2
(строк обработано: 2)
id
-----------
1
1
(строк обработано: 2)
*/

-- Выполняем dbo.sp_t1 от юзера u1
exec dbo.sp_t1 1
/*
Сообщение 229, уровень 14, состояние 5, процедура sp_t1, строка 1
Запрещено разрешение "EXECUTE" на объект "sp_t1" базы данных "tempdb", схемы "dbo".
*/

/*
-- Потом почистить за собой
drop table  dbo.t
go
drop procedure dbo.sp_t
go
drop procedure dbo.sp_t1
go
drop user u1
go
drop user u2
go

*/

Igor Korolyov

PaulWist
Да ладно Мастер - Детали.

И зачем запихивать всё это в 1 вызов? ...

Если "религия" - типа "весь доступ к БД должен быть через ХП" - то так и скажи - "это религия", и я отстану, т.к. спорить в этом случае бессмысленно. Если же есть какие-то СЕРЬЁЗНЫЕ технические преимущества - тоже интересно будет услышать. Я не вижу ничего существенного - да, пару % падения скорости, что некритично для систем интерактивного ввода.

Igor Korolyov

PaulWist
Ну и классика жанра, row-level вызов триггеров тождественно равная кол-ву записей в деталях, вместо одного вызова над набором модифицируемых данных.

...
В любом случае, каким же таким волшебным образом ты собираешься осуществлять модификацию (а не вставку или удаление) целой кучи записей за раз
staging таблицы? xml? С гениальнейшим последующим merge для переноса в основную таблицу Т.е. отрастить себе вот-такенный геморрой, чтобы потом им хвастаться

Igor Korolyov

PaulWist
Конечно нужно, все типы max можно получить только через СА

А нетути ни в db2 ни в оракле никаких varchar max, а имеющийся там clob безо всяких проблем вынимается что SPT что CAD...
Т.е. необходимость фиксить косяк драйвера ты ставишь во главу угла Ну так про это я и писал - да, "ручное" указание типов для этого может быть нужно... Правда не всегда его одного (т.е. самого по себе наличия схемы) достаточно - бывает и ещё кучу мер надо проводить, скажем настраивать сессию специальным образом.

Igor Korolyov

PaulWist
в предложенном случае будет хоть какое-то однообразие доступа и модификации данных, да с использованием "двух" технологий, но во всяком случае не надо будет вспоминать "где играли, а где рыбу заворачивали"

В предложенном мной способе будет полное однообразие для редактирования данных, с использованием одной технологии. А вторая останется для весьма специализированных случаев - те же вызовы расчётных ХП, настройка сессии (т.к. те же ALTER/SET команды ни в какие ворота "штатного DML" не влазят). При том вполне возможно что в системе описываемой автором темы этого вообще не понадобиться.

PaulWist
таким образом, что бы использовать CAD "напрямую" для второго select-a (exec dbo.sp_t1 1), надо текущему юзеру дать права другой роли/юзера/логина/сертификат и тп.

pasha_usue

PaulWist
таким образом, что бы использовать CAD "напрямую" для второго select-a (exec dbo.sp_t1 1), надо текущему юзеру дать права другой роли/юзера/логина/сертификат и тп.

Так-то, контекст олицетворения - моветон клиентам переключать. Обычно определяется на этапе проектирования БД. Функциям задаётся WITH EXECUTE AS...

PaulWist
Репо-код:

PaulWist
таким образом....

PaulWist
Пусть будет "религия"

PaulWist
Ну да, именно так, всё лучше чем "послать" 10 команд на модификацию

PaulWist
Как говорится, каждый сам себе злобный буратино.

PaulWist
как из Оракла SPT вынимает varchar(>8000)?

PaulWist
Это пример, что бы представить почему пара CAD-ов не может

Igor Korolyov

PaulWist
Репо-код:

Понятия не имею про что это, и особо вникать желания не возникло.

Igor Korolyov

PaulWist
Репо-код:

Но система где два раза подряд вызываемая одна и та же процедура на второй раз падает - IMHO должна отправится на свалку, вместе с её автором.

Igor Korolyov

PaulWist
Это пример, что бы представить почему пара CAD-ов не может

Я не специалист в MSSQL, но мне кажется что это более чем надуманная проблема.
Ещё раз - система где повторение простого действия вызывает ошибку (и это не связано с каким то "нарушением уникальности", или "исчерпанием лимита на что либо") - должна быть выкинута, и заменена на адекватный код. Уверен что и на MSSQL это не является неразрешимой проблемой.
А городить огороды с маловнятными дополнительными действиями/командами только чтобы гениаль-систем не валился с ошибками на каждом шагу - ну да, если хорошо платят, или есть склонность к мазохизму - тогда можно. Только ради бога не советуй никому такое

прошелмимо
что бы представить почему пара CAD-ов не может вынуть/модифицировать данные из одного соединения под одним юзером

угу.

вот тупо:
есть документ, пусть накладная,- у него есть заголовок/Header (номер, дата...) и детали/Details (суммы...) - на изменение Header - Аудит

наколбасил я, заполнил заголовок и 3 позиции (во 2 слово "Сиреневенький"), а на это слово у меня отлуп на сервере - Бага - Бага
+ на изменение каждой детали - Аудит

начал сохраняться:

1. сохраняю детали

сохранил 1 запись, отработал триггер
сохранил 2 запись - получил Баг
и все откатился

в итоге я не адейтил 3 деталь и не изменял хеадер
(у меня не выполнялись триггеры послед.деталей и заголовка док)

прошелмимо
это плохо?

pasha_usue
У меня эта схема как-раз на кадах реализована. Объект бизнес-логики открывает транзакцию, поочерёдно записывает свои кады в рамках транзакции. Затем либо ROLLBACK, либо COMMIT. Соответственно, если в какой-то момент сервер поднял ERROR, в этот момент сохранение останавливается как на сервере, так и на клиенте.
Только порядок сохранения от header к detail, так как header вернёт свой(и) первичный(ые) ключ(и).

PaulWist
Она правильно падает, поскольку "во второй раз" - нет разрешений для юзера

pasha_usue
порядок сохранения от header