Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
samonon Автор Сообщений: 1 Дата регистрации: 28.09.2015 |
Здравствуйте, предлагаю к обсуждению большую тему - выбор способов работы с данными в VFP (вопросы в конце поста).
Предыстория Я работаю с большим количеством унаследованного кода (формы, программы), работа с данными в котором построена ужасным образом, и новый код пишется аналогично. Так как такая ситация меня не устраивает полностью, то я решил выбрать наилучший (самый удобный/современный/распространённый) подход для работе с данными в Visual FoxPro. При изучении этого вопроса я рассмотрел работу с данными в самом VFP, работу через ADO и технологию ADO.NET. В итоге я пришёл к выводу, что необходимо писать библиотеку классов. Сначала я опишу задачу, потом текущее состояние разработки (под спойлером, но очень познавательно), потом ход моих мыслей и в конце - задам вопросы. Задача: 1) Внедрение единого подхода к работе с данными, независимо от источника (dbf или серверная база данных) 2) Внедрение современных методов работы с даными 3) Внедрение работы с классами 4) Написание кода, который можно было бы впоследствие перенести на другие платформы - (отказ от навигации по dbf таблицам и др). Описание текущего состояния разработкиПримерное направление для улучшения:1) Улучшение работы с DBF таблицами - использовать только SQL команды для работы с DBF таблицей, не использовать DBASE команды, зависяще от текущей записи. - добавить первичные ключи, там где их нет, для удобства работы SQL. - в дальнейшем отказаться от использования нативного доступа к таблицам и взамен использовать доступ по ODBC/ADO. - в дальнейшем отказ от использования таблиц FoxPro и перенос их на сервер 2) Писать новый код/переписывать старый код для удобства переноса на платформу 1С - доступ ко всем таблицам с помощью из 1С через ADO/ODBC 3) Разработка набора классов для работы с данными - см. далее. Способы работы с данными1) Нативный доступ к DBF таблицам - не рассматриваю, как устаревший формат хранения для приложений корпоративного уровня 2) SQL-passthrough (SQLEXEC) - протокол ODBC, нет инкапсуляции параметров, нет настройки курсора до выполнения команды. Самый старый способ, самый низкоуровневый, нет никаких настроек загрузки и меньше всего ошибок. 3) CursorAdapter (VFP 8+) (альтернатива - DataAdapter из ADO.NET) + улучшенные возможности по настройке процесса загрузки данных, улучшенная загрука в асинхронном режиме и загрузка Memo по требованию + улучшенное сохранение данных - поддержка Timestamp полей и улучшенное определение конфликтов + поддержка различных видов источников данных (Native, ODBC, ADO/OLE DB, XML) - специализирован для работы с одним курсором, только SelectCMD, нельзя напрямую выполнять произвольные команды. нельзя выполнять хранимые процедуры с возвращением результата - нет поддержки параметров (по умолчанию) - может быть добавлен визуально только в DataEnvironment. 4) ADO + есть классы, хоть и COM-компоненты, требует OLE DB драйверов, + расширенные возможности по работе с серверными курсорами + полная поддержка хранимых процедур с выходыми параметреами в извращаемыми занчениями + можно использовать в других приложениях (Excel, 1C?) - снижается скорость работы за счёт того, что используется COM-интерфейс? - работа с COM-классами. - работа с RecordSet, а не с FoxPro курсором. - основная проблема, что в нашем приложении ADO раньше не использовалось - будет сложно приучить людей к нему. 5) Набор классов из существующих фреймворков от сторонних разработчиков: + классы, разработанные программистами высокого уровня, и протестированные в реальных программах - большинство фреймворков написано на английском языке, который не знаю программисты. - приложение будет зависеть от ферймворка. 6) Самописные классы (например, напоминующие структуру ADO.NET) + можно разработать "правильную" иерархию, которая бы включала то, что мне нужно. - поддержка, разработка будет осложнена низким уровнем знаний программистов да и моим небольшим опытом. - нет смысла заморачиваться разработкой чего-то нового на устаревшей платформе. Лучше сделать минимальные набор классов для самых распространённых вариантов использования и успокоиться на этом. Необходимый функционал классов:1) Загрузка данных + CursorAdapter и ADO - самые большие возможности настройки процесса загрузки и результирующего кусрора до начала загрузки 2) Массовая модификация строк произвольными UPDATE,INSERT,DELETE + SQLEXEC (DBC) + ADO (OLE DB) 3) Выполнение хранимых процедур с выходными параметрами + SQLEXEC (DBC) + ADO (OLE DB) 4) Возвращение единственного скалярного значения - нет функционала по умолчанию. Нужно загрузить строку и выбрать значение первого поля первой строки 5) Последовательный доступ на чтение + ADO - есть специальный вид курсора 6) Серверный курсор + ADO - есть специальный вид курсора (connected mode) Требуются ваши мнения по следующим вопросам:1) Основная технология доступа к данным ODBC (SQL passthrough + CursorAdapter ) или OLE DB (ADODB.* + CursorAdapter) - ODBC используется на данный момент, имеет достаточную функциональность - ADO предположительно имеет более широкие возможности, но не используется в текущих задачах, требует обучения, имеет более низкую скорость работы (нужно протестировать). Используется в других языках гораздо чаще, так как работает с объектами, что, наоборот, является недостатков в VFP. - доступ к dbf таблицам можно также организовать через драйверы ODBC/OLE DB, но это снизит скорость работы и нужны будут сторонние драйверы 2) Выбор библиотек классов для работы с данными: - использовать классы ADODB.* напрямую или через класс-обёртку - использовать самописные классы для работы с источником данных (db_connection, db_command, data_adapter) и локальными данными (cursor_object/table_object) - необходимы для ODBCкомманд (SQLCONNECT, SQLEXEC, ...). Не окажется ли, что лучше сразу работать с ADO, чем писать свою библиотеку, которая будет похаже на корявую обёртку вокруг него. - использовать сторонние фреймворки, в том числе коммерческие. 3) Классы сторонних фреймворков - посоветуйте хорошие фреймворки. 4) Ресурсы - накидайте ссылок на книги, статьи, обуждения в форумах, где бы поднимались аналогичные вопросы. Резюмеместо для резюме по результатам обсуждения. Исправлено 1 раз(а). Последнее : samonon, 18.03.18 13:40 |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
spinz Сообщений: 5263 Дата регистрации: 21.01.2016 |
Рядом уже упоминали как здесь относятся к "требованиям" Тут к упомянутым 200$ можно смело нолик добавлять ------------------ Позовите санитаров |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Сомнительно что кто либо на форуме будет всерьёз заниматься ТАКИМ объёмом. По сути ты хочешь получить полностью архитектуру приложения... На мелкие вопросы гораздо больше шансов получить совет/мнение/предостережение. Начнём с простого - лично я не вижу смысла что либо вообще менять в VFP части. Фокс мёртв, тратить... ну "с потолка" скажу - лет 10 напряжённой работы на то чтобы получить в итоге более приемлемо написанную систему на VFP - в чём глубокий смысл? Если и переделывать хоть что-то, то сразу на ту систему с которой и собираетесь жить следующие 10-15 лет. 1с - ну пусть будет 1с - благо он несложный, для фоксовиков (нормального для них возраста 50+) должен быть довольно прост в освоении. Переделывать, конечно, мелкими но взаимосвязанными частями - параллельно дописывая код синхронизации/репликации из существующих таблиц. Это по крайней мере перспективный путь, в отличие от создания каркаса (пусть даже не с нуля, а взяв за основу чужой) и переписывания под него всего наработанного функционального объёма. Проблема в том, что так делать крайне неэффективно. Для dbf эффективен один подход - а именно "прямая" работа с ними, пусть и через курсоры/запросы/SQL с запретом на применение FILTER/RELATION/SEEK/SCAN к хранимым таблицам (хотя ко временным курсорам - вполне можно). SOA, микросервисы? Современно и перспективно, но на фоксе не взлетит... Нереально. Будет очень плохой код для dbf и не сильно лучший (в итоге) для других систем. Такого рода "универсализм" - путь в никуда. Лично я в этом проблем не вижу. Вот с exe на 100мб, и "изгнанием" всех юзеров из проги для любого мелкого фикса - это да, это очень серьёзная проблема. Разве что не стоит прямо с сети "запускать" - стоит с неё копировать изменённые файлы, а запускать уже чисто с локального диска прогу. Самое главное чтобы у таблицы был первичный ключ - конечно удобно если он суррогатный, но не обязательно. Вот если в принципе нет PK - т.е. набора полей однозначно идентифицирующих каждую запись - это беда... Как жы вы с ним работаете то Если остаётесь на этом сервере, то первым делом нужно найти DBA - может кого из своих, менее загруженных и более "шарящих" работников назначить. Пусть подтягивает знания и берёт власть в свои руки. Это ключевое - DBA должен стать "смотрящим", не допускающим "беспредела" в базе. На самом деле это ближе к Data Administrator, а не DataBase Administrator - но по бедности можно и совместить... Первое не сильно страшно, второе похуже, но тоже не критическая проблема. 5000+ схем/аккаунтов в БД на всех юзеров - не лучший вариант, тем более без DBA В первом проблем не вижу - мы и сами так работаем. Второе, конечно, безобразие... Это тоже не проблема Проблема это написать систему целиком на ХП, с большей частью бизнес-логики в этих ХП, и потом "вдруг" получить задание поменять СУБД - ну там к примеру ibm санкции ввела против вашего завода И попробуй ка ты перепиши всё это хозяйство на какой-нить "местный" Postgres Pro к примеру... Я бы сказал что кроме особо "тяжких" расчётов пихать в серверный код ничего и не стоит. Тривиальщину тем более. Вот пользоваться встроенными механизмами СУБД по поддержанию целостности (констрейны) - это другое дело - это надо. Не в прикладном коде писать проверки "там ссылаются, и там тоже, удалять нельзя". Кстати, совершенно поддерживаю такое мнение Для фокса адо - как для арабского скакуна телега Исключением/оправданием может быть лишь отсутствие вменяемых ODBC драйверов. Кстати, сам по себе ADO так же мёртв как и фокс Только для хранимых таблиц. Для временных курсоров - в т.ч. и полученных через тот же SQLEXEC - такой запрет не стоит вводить. Да, стоит убеждать использовать INSERT-SQL вместо APPEND+REPLACE, или там UPDATE-SQL вместо SCAN цикла с REPLACE-ом... Но "запрещать" я бы точно не стал. Это не критично для работы с курсором - главное чтобы не для хранимого dbf это использовалось. Тут даже не в "удобстве" вопрос. Удобство - это если PK суррогатные, да ещё и однотипные по всей БД - а так, это же обязательное требование к реляционной БД. КРАЙНЕ не советую так делать. Ходить к родным dbf-ам через пять заборов - верный способ угробить какую угодно хорошую систему. А вот это - совсем другое дело.
1с хорошо работает со своими родными, управляемыми системой сущностями (своими справочниками/документами/регистрами). С чужим - хоть через ado, хоть через что - это извращение. Для целей стыковки с другим ПО, начальной переброски информации из старой системы - да. Для работы как с основным хранилищем данных - нет и ещё раз нет. Это единственный адекватный способ работы с dbf-ами в фоксе. Учти, что курсорадаптер НЕ отменяет native доступ - хотя и может служить необходимым "посредником" между хранимым на диске dbf и тем курсором, с которым идёт работа в ПО. Кроссплатформенный, и наиболее стандартизованный вариант. Ещё и быстрый и "лёгкий" по сравнению с ADO. Лишь бы драйвер был адекватен. Да, как "универсального посредника" его можно применять - в т.ч. если аккуратно и обдумано писать работу с получаемым от него курсором, то в принципе можно будет делать замену "CAD на dbf" на "CAD на серверную таблицу" сравнительно безболезненно. А зачем его вообще куда либо "визуально" добавлять? Чтобы на форму текстбоксы и гриды таскать "уже самонастроенные"? Или в Property Window в комбобоксах видеть имена полей? Не уверен что это настолько уж важные функции И не надо. Это самый убогий вариант из всех возможных. Два курсорных движка в программе... Если бы фокс умел поддерживать ТОЛЬКО OLEDB провайдеры (т.е. напрямую их использовать, без обёртки курсоро-подобного движка ADO) - ну то другое дело, а так - не стоит. Именно. Вкладываться серьёзно в разработку фреймворка и перевод под него серьёзной программной системы - и всё это на VFP - сегодня нецелесообразно. Нормально. CAD можно нарастить своим функционалом - как прикладным, так и системным (то же восстановления потерянного соединения - конечно не сам по себе, но вместе с другими классами...). Не надо. Очень не советую. ------------------ WBR, Igor |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
spinz Сообщений: 5263 Дата регистрации: 21.01.2016 |
И не лень же Игорю....
------------------ Позовите санитаров |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
Придётся скрещивать ежа и ужа SPT и CA имеют свои недостатки. СА: - При select нельзя получить несколько курсоров. - Обновление источника данных происходит "позаписно" (сильно аукается, когда на табличку навешаны триггеры) SPT: - Нельзя получить с сервера курсор с необходимой схемой - "новые" типы данных не поддерживаются (n/varchar(max), XML и др.) как резюме, для большинства задач подойдёт: - Извлечение данных с помощью СА. - Сохранение/модификация c помощью SPT. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
В контексте одного обращения к БД (скажем одного вызова ХП)... А насколько это актуально? Т.е. чем плохо сделать 2-3 или сколько надо CAD с отдельными запросами/вызовами? Так 99% работы с данными и происходит "позаписно". Массовые операции - сравнительно нечастая штука, и как раз таки их и имеет смысл изолировать в ХП на сервере (если они не сверх-гибкие, т.е. заранее неизвестно чего как надо обновлять/создавать - только из кода клиента можно создать соответствующие команды). Опять же а какова цель? IMHO крайне вредно когда структура курсора заметно отличается от результата запроса, и происходит то или иное неявное преобразование. Конечно, есть исключения, скажем datetime "урезать" до date (если вдруг серверный date всё равно через odbc придёт как datetime, или на сервере в принципе нет типа date, а бизнес-логика не нуждается во "времени"), да и ошибки/особенности в реализации ODBC драйверов таки бывают (когда вместо double(5) зачем-то в фокс приходит какой-нить неадекватный number(10,0))... Т.е. оно и полезно, но оно же и опасно - сколько ошибок допущено именно из-за несоответствия схемы реальному результату запроса... И ведь не все они сразу видны, т.е. формально "ошибки" и не возникает - возникает странное поведение, потеря данных... А оно нужно для "старой" системы? Да и для новой вполне можно обойтись и без "хитрых типов" - они таки сильно неуниверсальны. Вот в том же db2 (и оракле, кстати) никаких varchar(max) нет и в помине Только выполнение специфических "массовых" операций - а это IMHO 1% случаев. Для типичной работы оператора со вводом данных в гриды/формы, это (вынимать через CAD, а сохранять через SPT) будет совершенно неэффективно и избыточно. ------------------ WBR, Igor |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
1. Это ограничение СА. 2. Для многодетальных отчетов очень актуально,... согласен, что таких отчетов немного, но они есть. 3. Не всегда возможно получить доступ к объектам, например к тем, которые выполняются от другого контекста олицетворения.
Да ладно Мастер - Детали. Ну и классика жанра, row-level вызов триггеров тождественно равная кол-ву записей в деталях, вместо одного вызова над набором модифицируемых данных.
Конечно нужно, все типы max можно получить только через СА, например forum.foxclub.ru
Впрочем, каждый волен идти "своим путём" ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
прошелмимо Сообщений: 784 Дата регистрации: 21.02.2012 |
1. Это ограничение СА.
Это так было задумано. 1 КА работает с одним привязанным курсором. И правильно. Ограничение в мозгу. 2. Для многодетальных отчетов очень актуально,... согласен, что таких отчетов немного, но они есть. ну так и селекти как хочешь. нафига тебе КА для того, чтобы только прочитать? 3. Не всегда возможно получить доступ к объектам, например к тем, которые выполняются от другого контекста олицетворения. ничего не понял, кому куда и кого получить? Мастер - Детали. ну и в чем проблемы? поднимаются каскадом КА и сохраняются дети, потом родители. ну и вызовутся детские триггеры 100 детей 100 раз и т.д., а потом триггеры родительские. (хотя если надо, - можно и отключить, зачем не понимаю). зачем именно один вызов над набором модифицируемых данных? пыс пыс 10 лет вынужден жить без триггеров вовсе. (месть немцев за проигранную 2 мировую). |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Это его логика. В чём проблема сделать 2-3 или сколько надо отдельных запросов, отдельных CAD объектов? Понятия не имею про что эти слова. Но все требуемые CAD вполне могут (да и обычно должны) работать через одно соединение. Как там может быть разным хоть что-либо между 2-мя последовательными запросами, тем более SELECT-ами ничего в БД и в сессии не меняющими - для меня загадка. И зачем запихивать всё это в 1 вызов? Нет, ну если бы это было "бесплатно" - то и фиг с ним, но специально бороться с системой, городить огороды ради того чтобы зачем-то запихнуть 10 записей (при том вводимых пользователем вручную, не мега-погрузки из 100500-строчных внешних источников) за одно обращение/один вызов ХП? Нет, я на самом деле не понимаю ЗАЧЕМ. Если "религия" - типа "весь доступ к БД должен быть через ХП" - то так и скажи - "это религия", и я отстану, т.к. спорить в этом случае бессмысленно. Если же есть какие-то СЕРЬЁЗНЫЕ технические преимущества - тоже интересно будет услышать. Я не вижу ничего существенного - да, пару % падения скорости, что некритично для систем интерактивного ввода. И в чём проблема? Для оракла вообще основная обработка зачастую идёт именно в row-level триггерах, и лишь "особые случаи" выносят в statement-level - при том что там ещё надо специально "собирать" (в тех самых row-level триггерах) какие же записи/строки были изменены/добавлены/удалены - если по логике триггера ему надо было бы зачем-то это знать... Да, я в курсе что в MSSQL нет row-level триггеров, посему большинство задач разумно решаемых именно таким типом триггеров, в mssql решаются через *опу - вот только автор писал про оракл и db2 (там тоже есть row-level триггера наряду со statement-level) - так зачем ему mssql-ную ущербность то изучать, и ориентироваться на неё В любом случае, каким же таким волшебным образом ты собираешься осуществлять модификацию (а не вставку или удаление) целой кучи записей за раз staging таблицы? xml? С гениальнейшим последующим merge для переноса в основную таблицу Т.е. отрастить себе вот-такенный геморрой, чтобы потом им хвастаться А нетути ни в db2 ни в оракле никаких varchar max, а имеющийся там clob безо всяких проблем вынимается что SPT что CAD... Т.е. необходимость фиксить косяк драйвера ты ставишь во главу угла Ну так про это я и писал - да, "ручное" указание типов для этого может быть нужно... Правда не всегда его одного (т.е. самого по себе наличия схемы) достаточно - бывает и ещё кучу мер надо проводить, скажем настраивать сессию специальным образом. В предложенном мной способе будет полное однообразие для редактирования данных, с использованием одной технологии. А вторая останется для весьма специализированных случаев - те же вызовы расчётных ХП, настройка сессии (т.к. те же ALTER/SET команды ни в какие ворота "штатного DML" не влазят). При том вполне возможно что в системе описываемой автором темы этого вообще не понадобиться. Лично мне вот никогда не требовалось для целей пользовательской работы с данными (там где применяется CAD) городить дополнительную систему для использования SPT. Хотя те же генерируемые фоксом команды в обработчиках CAD Before* я в некоторых случаях модифицировал - например добавлял returning опцию к INSERT для получения назад с сервера автосгенерированного триггером id. По сути CAD это и есть средство "автоматизации" SPT - он управляет курсором, он сам строит DML команды, но и позволяет их и "донастроить" и вообще самому прописать с нуля (если уж так впилось "доступ к данным только через ХП"). Смысла навешивать на CAD ещё слой который будет именно SPT пользовать... Я не вижу вообще. Ну разве что да, заменить простые как грабли INSERT/UPDATE/DELETE команды на каких-то монстров "собирающих" 100500 изменений в один мега-пакет и каким-то волшебным образом эти изменения потом на сервере "применяющие". Затея которая мне кажется даже не просто сомнительной ------------------ WBR, Igor |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
Да, хорошо, by design.
Репо-код:
таким образом, что бы использовать CAD "напрямую" для второго select-a (exec dbo.sp_t1 1), надо текущему юзеру дать права другой роли/юзера/логина/сертификат и тп. Ну если ходить через sa/sysadmin/sysdba, то конечно проблем не возникнет.
Пусть будет "религия" мы вроде уже по этому поводу договорились
Ну да, именно так, всё лучше чем "послать" 10 команд на модификацию, а потом если триггеров только три, то в ТРИ раза больше вызовов триггеров - 30 раз, вместо "одной" (фактически трёх) команды DML и ТРЁХ вызовов триггеров. Как говорится, каждый сам себе злобный буратино.
Э-э-э да, кривизну драйвера приходится "лечить" CAD-ом, кстати о птичках, как из Оракла SPT вынимает varchar(>8000)?
Дык, ТС-у самому выбирать технологию, каждый волен пройти по собственным "граблям" ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
pasha_usue Сообщений: 3650 Откуда: Е-бург Дата регистрации: 06.10.2006 |
Так-то, контекст олицетворения - моветон клиентам переключать. Обычно определяется на этапе проектирования БД. Функциям задаётся WITH EXECUTE AS... |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
Это пример, что бы представить почему пара CAD-ов не может вынуть/модифицировать данные из одного соединения под одним юзером, а SPT может вынуть/модифицировать, более того, так же вернуть несколько наборов. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 20.03.18 14:20 |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Понятия не имею про что это, и особо вникать желания не возникло. Но система где два раза подряд вызываемая одна и та же процедура на второй раз падает - IMHO должна отправится на свалку, вместе с её автором. Надо быть проще, и всякую хрень не использовать Автору темы это не грозит априори, т.к. никаких MSSQL заявлено не было. Ок, тогда No Comments Только уж не говори что у других будут какие-то жуткие проблемы - они просто не будут твой подход использовать (что IMHO совершенно оправдано - простота, конечно, хуже воровства, но и "горе от ума" никто не отменял). Tastes differ... +100500! В оракле в SQL нет таких типов. максимум 4000 байт (что может значить и всего 1000 символов - в зависимости от кодировки БД). docs.oracle.com PL/SQL-ный тип varchar это совсем другое - и его что извлечь что послать, насколько я помню, можно без проблем (именно в ХП - к "SQL запросам" это не имеет ни малейшего отношения - его и в самом оракле невозможно передать в SQL контекст - там попросту нет такого типа, как и того же boolean к примеру). Я не специалист в MSSQL, но мне кажется что это более чем надуманная проблема. Ещё раз - система где повторение простого действия вызывает ошибку (и это не связано с каким то "нарушением уникальности", или "исчерпанием лимита на что либо") - должна быть выкинута, и заменена на адекватный код. Уверен что и на MSSQL это не является неразрешимой проблемой. А городить огороды с маловнятными дополнительными действиями/командами только чтобы гениаль-систем не валился с ошибками на каждом шагу - ну да, если хорошо платят, или есть склонность к мазохизму - тогда можно. Только ради бога не советуй никому такое ------------------ WBR, Igor |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
прошелмимо Сообщений: 784 Дата регистрации: 21.02.2012 |
Как говорится, каждый сам себе злобный буратино.
гммм, интересно, какую траву курите? может тоже жахнуть? что бы представить почему пара CAD-ов не может вынуть/модифицировать данные из одного соединения под одним юзером угу. вот тупо: есть документ, пусть накладная,- у него есть заголовок/Header (номер, дата...) и детали/Details (суммы...) - на изменение Header - Аудит наколбасил я, заполнил заголовок и 3 позиции (во 2 слово "Сиреневенький"), а на это слово у меня отлуп на сервере - Бага - Бага + на изменение каждой детали - Аудит начал сохраняться: 1. сохраняю детали сохранил 1 запись, отработал триггер сохранил 2 запись - получил Баг и все откатился в итоге я не адейтил 3 деталь и не изменял хеадер (у меня не выполнялись триггеры послед.деталей и заголовка док) это плохо? |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
Если будет желание docs.microsoft.com , technet.microsoft.com
Она правильно падает, поскольку "во второй раз" - нет разрешений для юзера, IMHO как раз система которая не падает при отсутствии разрешений должна ещё быстрее отправится на свалку, вместе с её автором.
Ситуация вполне рабочая, когда в БД используются штатные механизмы безопасности СУБД! А когда к данным "ходят" через админский логин-пароль, и разделение прав осуществляют через Enable/Disable/Visible элементов меню, кнопок, и тп, то именно такая система должна быть выкинута, и заменена на адекватный код. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
прошелмимо Сообщений: 784 Дата регистрации: 21.02.2012 |
когда в БД используются штатные механизмы безопасности СУБД!
ну и в чем не выполняются штатные механизмы безопасности СУБД в приведенном выше примере? юзер залогинился под собой. нет полномочий или на чтение/или на изменение в чем проблема поднять 2 КАДа и т.д. зачем городить кучу ХП и т.д. и курить травку? |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
прошелмимо Сообщений: 784 Дата регистрации: 21.02.2012 |
А когда к данным "ходят" через админский логин-пароль, и разделение прав осуществляют через Enable/Disable/Visible элементов меню, кнопок
Вы считаете, что я в БД под одним логином? И имел такой опыт разработки? |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
pasha_usue Сообщений: 3650 Откуда: Е-бург Дата регистрации: 06.10.2006 |
У меня эта схема как-раз на кадах реализована. Объект бизнес-логики открывает транзакцию, поочерёдно записывает свои кады в рамках транзакции. Затем либо ROLLBACK, либо COMMIT. Соответственно, если в какой-то момент сервер поднял ERROR, в этот момент сохранение останавливается как на сервере, так и на клиенте. Только порядок сохранения от header к detail, так как header вернёт свой(и) первичный(ые) ключ(и). Это хорошо. Исправлено 1 раз(а). Последнее : pasha_usue, 21.03.18 14:14 |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
У нас тоже, правда "порядок сохранения" там гораздо интереснее - сначала от самых глубоких деталей "наружу", к шапке, идут удаления, а потом от шапки вниз идут update/insert. Да, конечно же в рамках транзакции, какой бы "бедной" она не была в фоксе с его SQLCOMMIT-ом... При этом и констрейны и триггера на серверной стороне работают безо всяких проблем. Это как? Каждую чётную секунду есть, а каждую нечётную нет Права должны быть Клиент вообще не должен ничего ни про какие серверные прибабахи знать. Он залогинился и работает - так как ему удобно. Удобно батчем загонять 100 записей (и если "коннектор" - будь то ODBC/OLEDB/ADO.NET или кто угодно ещё - это позвоялет) - пусть загоняет. Удобно по одной записи сохранять - при том что каждая из них по своей сути НЕ нарушает никаких ограничений в СУБД, т.е. не является заведомо ошибочной - пусть так сохраняет. А диктовать ему что "ты только через 1 ХП и 1 вызов делай - будь там 1 запись, или 100500" - это бред. Права должны быть инвариантны, и никак не зависеть ни от порядка DML операций, ни от объёма передаваемых данных (ну разве что именно объём это самое "право" и ограничивает - но это уже не совсем разграничение доступа, это управление ресурсами). Если я могу запросить таблицу - через select или через ХП, не важно - то я могу это сделать и 1 раз и 100500 раз подряд. Да и не подряд а с "перемешиванеим" ещё кучи других операций. Система где наличие доступа зависит от того что я делал до этого (НЕ касаясь собственно операций авторизации - конечно же если я деавторизовался, то мои права аннулируются) - это не система а самое настоящее г*но ------------------ WBR, Igor |
Re: Современные методы работы с данными - OBDC, ADO(OLE DB) и библиотеки классов - Обсуждение | |
---|---|
прошелмимо Сообщений: 784 Дата регистрации: 21.02.2012 |
а может и у меня так было. я уже все забыл нафиг. лет 5 вааще не кодил и не кодю на фокспре. все, - кирдык. |
© 2000-2024 Fox Club  |