1) Да. Показанная вам демо версия позволяет работать лишь с MySQL. Частично с MSSQL.

2) Никто кроме вас этого не понял.

3) Среда уже "меняет" код старта транзакции.

4) Одинаковых записей в FB не будет, хотя бы потому что FB поддерживает Serialized, в случае тупой БД найдется способ синхронизации клиентов.

SeVa:
Существенные для нас различия в работе транзакций определяются режимом изоляции, а не отсутствием версионности у СУБД.

Результат у MS и MY будет идентичным, только пользователи MS больше будут простаивать.

Читаем SQL92

SeVa:

Я больше не буду комментировать вашу глупость,
учерен что читатели оценили ваши перлы. Особенно:

"Если уровень изоляции READ COMMITED, то блокировки держатся только
на время выполнения запроса, таким образом, все читают и перезаписывают
одно и тоже."


Posted via ActualForum NNTP Server 1.4

xЧастично с MSSQL.

Пока в MSSQL нельзя разархивировать базы данных, и
полноценно БД (триггеры, пользователи). Тоже качается и
остальных баз данных, пока некогда расписывать фукции
createTrigger, createUser, deleteUser, bulkInsert...


Posted via ActualForum NNTP Server 1.4

iscrafmв MS SQL можно архивировать базы данных, содавать триггеры,
добавлять
пользователей. Вы что, пытаетесь всунуть административную работу с
СУБД в свою программу?

Из администраторский функций лишь:

1) Архивирование. Оно необходимо для переноса баз данных между серверами
БД разных типов.

2) Создание пользователей. Среда помимо создания учетной записи, настроит её
права
доступа ко всем таблицам, вьюхам, полям, хранимкам и т.п. И будет
контроллировтаь
права досутпа всех учетных записей во время работы.

Незачем ради создания учетной записи еще одного работника лезть в SQL
Manager (к примеру).
Но если кто то добавит пользователя, среда предупредит об этом.

Остальное программирование:

1) Создание, удаление, изменение - таблиц, полей таблиц, FK, представлений,
индексов,
триггеров, хранимых процедур...

2) Перевод с внутреннего SQL-92 на SQL используемой СУБД

3) Накопление информации об изменении базы данных для обновления
баз даных клиентов. Например вы переименовали поле БД.

4) Контроль идентичности описания базы данных и состяния СУБД. Если
администратор добавит новое поле, среда сообщит об этом.


Posted via ActualForum NNTP Server 1.4

Один оффтопик.

Покажите мне задачу/программу в которой была бы необходима длинная транзакция.

Пока ответы были лишь "Потому что надо!".

xСкрины своей проги выкладывать не вижу нужды, если ты говоришь
"заказчик дурак"

Я этого никогда не говорил.

Я как программист (и как конечный пользователь) не могу представить задичи,
где бы применение длинных транзакций было оправдано. Критерий оправданности
это отношение "плюсов к минусам"

Минусы:
- СУБД позволяющая работать с длинными транзакциями без блокировок.
- Дополнительная нагрузка на сервер
- Требования к надежному соединению
- Больше обращений к серверу.
- Множество открытых соединений
- Большую часть программы необходимо писать на недоразвитом языке СУБД.
- Сложнее перенос и масштабирование.

Плюсы:
- Большая часть программы пишется на сервере СУБД


Posted via ActualForum NNTP Server 1.4

Вопрос не в этом.

Если требованием заказчика будут длинные транзакции - то
будем писать такую программу. В отличии, о TRDM который
переделывал все ТЗ на предприятии. Мне всегда говорили -
денег ты с этого не получишь, а вот (финансовой) ответственности
отгребешь.

Если поставленную заказчиком задачу можно выполнить лишь
с использованием ДТ (проще выполнить с ДТ) - то будем писать
такую программу.

Вопрос "Зачем длинные транзакции?"

Я не представляю задачи, в которую было бы невозможно
решить обычным (для меня) походом:

1) При нажатии на кнопку ОК (запись данных в БД), хранимая
процедура/триггер проверяет корректность записываемых данных.

Например, не дает уменьшить значения поля таблицы.



1.1) Возможно перерасчет - промежуточных результатов

1.2) Сброс рассчитанных промежуточных результатов

2) Программа (написанная на клиенте) позволяет избежать ошибок

возникающих в 1. Например, предупреждает при уменьшении

значения поля таблицы, о недостаточных правах доступа.




Posted via ActualForum NNTP Server 1.4

iscrafm

- Большую часть программы необходимо писать на недоразвитом языке СУБД.

во-первых это никак не связано с "длиииными транзакциями"





Согласен, не с той стороны посмотрел.



iscrafm

во-вторых не нужно так категорично о "недоразвитости" языков СУБД.

У нас, к примеру, на Firebird или MS-SQL прописана вся логика сложной

маршрутизации docflow в системе документооборота, на Firebird или

ORACLE логика проектной системы, на T-SQL (MS SQL) автомат MRP,

бюджетирования и еще много чего, что просто задолжаешься

программировать на "развитых" языках.





Программировать "сложные программы" можно и на бреинфаке. Уверен, что

аналогичная программа на C# написанная с использованием возможностей C#

была бы проще и понятнее.



Какие особенности TSQL позволяют менее "задолбаться" при разработке

программ?






Posted via ActualForum NNTP Server 1.4

xлочить все записи таблицы

Я 100 раз написал что лочатся записи относящиеся к открываемому документу.


Posted via ActualForum NNTP Server 1.4

iscrafmАлексей, я конечно программист в душе, но в тоже время
разработка....

Вы не привели ни одного аргумента, почему C# это плохо.
А я могу сказать, что основной закон разработки - это на чем умеем, на том и
пишем.

В глубине души, мне самому не особо нравится C# (в эту же группу языков,
относительно применения, я грубо отнесу и Java)
Но толи Microsoft/Sun навязывает применение этого инструмента для написания
бизес-логики и алгоритмов обработки данных, то ли действительно это так
круто - но они повсеместно применяются.

Посмотрите статистику в интернете.


Posted via ActualForum NNTP Server 1.4

iscrafn

Просто у вас нет аргументов.

У нас с вами с самого начала не получилось конструктивного разговора,
исходя из написанного мне лично о вас другими учасниками форума
я и не удивлен.


Posted via ActualForum NNTP Server 1.4