После однократного прочтения...

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

после второго прочтения понял, что я немножко не об этом....

А что, на TblPhones.ID действительно есть внешние ссылки? Просто непонятно, зачем, это подчиненная информация вроде как...

В принципе, я не вижу большой проблемы в синхронизации временной таблицы с постоянной в вашем варианте.
Транзакция будет состоять из трех запросов UPDATE, DELETE и INSERT, и полностью синхронизирует временные данные с постоянными.

orunbekМожно использовать следующий метод для подтверждения редактирования существующего контакта:

и что вам в нем не нравится?

orunbekВы о таком методе имели в виду?

Именно. Но он оказывается уже у вас написан, я думал, проблема в самом написании....

orunbekвсе устраивает, в принципе
просто думаю, может быть кто-то решил подобную проблему более эффективным и "элегантным" способом, как бы вынес решение проблемы на обсуждение, для нахождения "слабых мест" ;))

Раз ID трогать нельзя, то это ИМХО - единстенный возможный способ.

Использовать транзакции, даже если бы это было возможно, нежелательно, ибо зачем блокировать страницы, пользователь же полдня может заниматься редактированием данных

orunbekпроблема использования транзакций даже не в этом, а в другом

Не, это как раз не проблема, разумеется новая транзакция должна открываться в новом соединении.

orunbekВроде бы есть лимит количества открытых транзакций на одно подключение в ADO...
Или я ошибаюсь?

Я ведь уточнил - В НОВОМ соединении (подключении, коннекшне)

Честно говоря не очень в курсе, возможно в ADO можно открывать именованные транзации и в одном соединении, однако он сам прозрачно для пользователя будет открывать новые коннекшены.

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

orunbekесть ограничение :((, в клиенте работать только через одно подключение

Один экземпляр коннекшна или одно фактическое соединение с сервером? В некоторых случаях это может быть не одно и то же

White Owl"BEGIN" и "BEGIN TRAN" это две очень разные вещи. Вообще, использовать BEGIN TRAN вредно.

Ну-ка ну-ка. Что-то очень много новостей за один раз.

1) Зачем здесь конструкция begin-end? Что изменится, если ее не будет?

2) Почему использование транзакций вредно? Лючшие умы не один десяток лет бьются над использованием транзакций, над уровнями изоляции и т.п., вдруг приходит White Owl и говорит, что это вредно. А мужики-то не знали

White OwlПросто формируешь строку с update и послыаешь ее.

3) Что ты предложил нового?

White OwlНе надо говорить глупости.

4) Спорить будем? Сразу говорю, я не пробовал ситуацию создавать специально и отслеживать активные соединения, так что мы в равных условиях

Shocker.ProWhite OwlНе надо говорить глупости.

4) Спорить будем? Сразу говорю, я не пробовал ситуацию создавать специально и отслеживать активные соединения, так что мы в равных условиях

Вот демонстрация "сказанной глупости":


ConnectDBNet() - моя функция установки соединения с SQL-сервером, расписывать смысла нет, курсор используется серверный.

Если раскомментировать команду Stop, то в списке процессов на серверы видны два соединения. В файрволе я вижу два TCP-соединения (я работаю по TCP/IP). Хватает аргументов?

Оговорюсь, я сам использую только хранимки и Forward/ReadOnly для рекордсетов, но речь идет о том, что ADO может создавать дополнительные соединения, не имея на то прямого указания программиста.

White OwlShocker.Pro1) Зачем здесь конструкция begin-end? Что изменится, если ее не будет?Послать пару команд можно и без них, верно. Но для создания переменных, надо делать блок.
Одна команда упадет, другая выполнится.


Давай определимся с языком. Автор пишет на MSSQL, а ты какой привел в пример?


White Owlот когда играют уровни изоляции, (а это происходит только когда несколько разных людей одновременно лезут в базу) тогда транзакции полезны. А когда ты создаешь транзакцию вручную, то ты на самом деле создаешь не просто транзакцию, а так называемую "вложенную транзакцию" со всеми плюшками и гадостями которые эти вложенные транзакции за собой тянут. Простую транзакцию тебе сервер создает автоматически при посылке любой команды если предыдущая транзакция была закрыта.

Похоже, мы говорим о каких-то разных серверах.
MSSQL создает неявную транзакцию, если я не задал ее явно. Если я явно указал "begin than" в пакете (как у автора), то никаких дополнительных транзакций больше не будет. Счетчик вложенных тразнакций покажет 1.

White Owlbegin tran - это как раз и есть вложенные транзакции, которые подчиняются правилам цепочности, парности подтверждений и непарности откатов, и прочим радостям жизни.

begin tran - это любые транзакции, а не только вложенные.

White OwlБольше скажу: не существует на свете задачи которая действительно требовала бы использования begin tran.

Одну ты назвал сам - многопользовательская работа. Вторая - целостность базы, откат в случае неудачного выполнения предыдущих команд. Думаю, этого достаточно на первое время.

Автор грамотно поступает, выполняя последовательность взаимосвязанных команд внутри транзакции, обеспечивая тем самым целостность данных даже в случае сбоев.

White OwlShocker.ProWhite OwlПросто формируешь строку с update и послыаешь ее.
3) Что ты предложил нового?Ничего. У orunbek в первом посте была предложена совершенная фигня с временными таблицами, а вашу дальнейшую переписку я проглядел по диагонали. Если ты это уже предлагал, то ура.

Ты предложил грубо говоря перегружать данные в массив на клиенте, а потом выгружать обратно в базу (все теми же командами update/delete/insert). Если же ты против временной таблицы для редактирования многострочного контента, то я поддерживаю автора, ибо сам к этому пришел после 14-ти лет проектирования клиент-серверных приложений. Я испльзую, правда, не временную таблицу, а единую таблицу для временных данных редактирования для всех пользователей. но сути дела это не меняет.

White Owl
Чистый VBS. Два курсора открываются одновременно. Сервер SA11.


1) как работает sa_conn_info я не знаю

2) твой код не доказывает того, что не бывает ситуаций установки второго коннекта. Мой код доказывает, что бывает. Почему я должен опровергать твой код, ты мой опровергни.

White OwlTransact SQL в вариации для MS SQL 2008. А, ну да, забыл @ у переменной поставить, прошу прощения.
Так лучше?

Одна команда упадет, другая выполнится.

Да, только пальцем в небо. Ибо обе эти строки выполнятся абсолютно одинаково и безошибочно.
a=b+с
a=(b+c)
Вот примерно это ты и написал. Как Си-шник ты должен прекрасно понимать, что такое операторные скобки (это в VB их нет)

White OwlДа, если begin tran просто так послать то первый раз она будет проигнорирована, на второй и дальше начнется вложеность. Насколько ты уверен что где-то выше по коду или вообще в другом окне ты уже не послал однажды begin tran?
White OwlShocker.Probegin tran - это любые транзакции, а не только вложенные.Это только вложенные.

Вложенность - это когда нечто одно вложено в нечто другое. Если begin tran встречается только один раз, то ничего ни во что вложено не будет.
Про то, что она будет проигнорирована - ты уже какую-то глупость несешь. После begin tran с первой операции с таблицами пойдут блокировки на эти таблицы (в зависимости от уровня изоляции). При rollback будет откат всех операций, начиная с begin. Сделать rollback для неявной транзакции (в MSSQL) невозможно (кроме триггера).

Почитай про @@TRANCOUNT, поэкспериментируй.

White OwlМногопользовательская работа не требует явного начала транзакции.
Откат всегда будет делаться на начало автоматической транзакции а не на begin tran.

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

White OwlА без точки сохранения ты всегда будешь откатывать до самого внешнего begin tran в случае вложенных транзакций либо до begin tran который совпадает с началом автоматической транзакции.

Разумеется, для того он и нужен. И у автора выполнится откат транзакции из трех операций на начало пакета.

White OwlShocker.ProАвтор грамотно поступает, выполняя последовательность взаимосвязанных команд внутри транзакции, обеспечивая тем самым целостность данных даже в случае сбоев.
Нет. Он поступает глупо.
а) Никто не гарантирует что в другом окне пользователь не пошлет другую begin tran (и кстати TC об этой проблеме догадывается, смотри самый первый пост).

Опять бред. Когда в другом окне пользователь пошлет другой begin tran, он сможет это сделать только в другом соединении. Он НИКАК не сможет допустить вложения в тот пакет, который в этот момент выполняется, ибо пакет цел и неделим от begin до commit и отправляется целиком на сервер (в варианте ТС-а).

Если же ты рассматриваешь ADO -шный метод .BeginTrans - то я тоже против его использования по примерно тем причинам, про которые говоришь ты, об этом я писал выше ТС-у.

Shocker.Proб) Целостность гарантируется тем что в случае сбоя сервер откатит все что не было подтверждено.

Верно. У ТС-са такой порядок:
begin tran
insert
delete
update
commit tran
Если на update произойдет сбой, то откатится и insert и delete. Если же убрать транзакцию, то insert и delete закоммиттятся, а update откатится/


Shocker.ProДа. Это самый надежный и простой метод работы. А что, кто-то еще пользуется DBGrid'ами?

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

White OwlShocker.ProЕсли же ты против временной таблицы для редактирования многострочного контента, то я поддерживаю автора, ибо сам к этому пришел после 14-ти лет проектирования клиент-серверных приложений. Я испльзую, правда, не временную таблицу, а единую таблицу для временных данных редактирования для всех пользователей. но сути дела это не меняет.ээээ.... в 14 лет уже надо бы понимать как работают транзакции... Впрочем, юноша, у вас еще все впереди :)

без перехода на личности обойдемся

По поводу двух соединений: возможно драйвер SyBase-а и позволяет открыть параллельную транзакцию (не вложенную) и ADO этим пользуется. Но в SQL для открытия параллельной транзакции он вынужден открывать и параллельное соединение.

White OwlВо вторых, я попытался намекнуть что коннекты к серверу устанавливает не ADO, а интерфейсный драйвер и если он считает что надо открывать второй коннект, к ADO это никоим образом не относится.

Гм. На таком уровне спорить не готов.
Тогда я пас, а свое утверждение переформулирую в:
При использовании ADO возможно возникновение дополнительных соединений с сервером без явного желания программиста

Именно это расстраивает ТС

White OwlShocker.ProДа, только пальцем в небо. Ибо обе эти строки выполнятся абсолютно одинаково и безошибочно.Ок. Признаю, этот test-case излишне упрощенный. Завтра я тебе сделаю программку выдающую 111-ую ошибку если не использовать операторные скобки.

А зачем ты передергиваешь? Речь шла о том, что твой совет ТС-у поставить операторные скобки вокруг двух его инсертов не имеет смысла.
Впрочем, очень интересно увидеть 111-ю ошибку для begin (кроме, разумеется, тех мест, где это положено по синтаксису, например в неинлайновой процедуре)

White OwlShocker.ProПочитай про @@TRANCOUNT, поэкспериментируй.Вот-вот. Почитай, поэкспериментируй.

пожалуйста

результат
0
1
0
никакой вложенности не наблюдаю.

White OwlА что, у автоматической транзакции нету явного начала? Она расплывчато начинается?

Нету явного оператора начала. Она начинается перед командой и заканчивается сразу после нее.

White OwlА уж влиять на транзакции из триггеров это вообще приглашать в гости большого и жирного песца.

А я этого и не предлагал. Я просто упомянул об этой возможности, чтобы ты не придрался к моему утверждению, что нельзя повлиять на выполнение скрытой транзакции.

White OwlВ пакет - не сможет, в несколько следующих друг за другом команд - сможет запросто.

У ТС-а был именно пакет. Зачем передергивать.

White OwlShocker.ProВерно. У ТС-са такой порядок:
begin tran
insert
delete
update
commit tran
Если на update произойдет сбой, то откатится и insert и delete. Если же убрать транзакцию, то insert и delete закоммиттятся, а update откатится/Ээээ... чего-чего? С чего это вдруг insert и delete будут откатываться???

Ибо не коммитили.

White OwlНе я первый попытался давить годами. И кстати, у меня все равно больше :)

А я не пытался давить. И уж тем более не говорил этого в контексте транзакций. Просто упомянул, что время у меня было, чтобы попробовать различные варианты хранения редактируемых данных.

White OwlСкандирую: ADO здесь ни при чем! ADO здесь ни при чем! ADO здесь ни при чем!
Не обвиняйте враппер в грех драйвера.

Тихо-тихо. Уши заложило. Я ведь уже согласился.

orunbekдела были, отходил
по поводу скрытых подключений, я на своей практике видел такое
тема по этому поводу
Аудит изменений через CONTEXT_INFO

Да, придется White Owl-у спорить с GreenSunrise - а это сложнее

Konst_Oneскрытые подключения - это результат вашего кода

В моем коде таких конструкций нет:

Konst_Oneвы с чем боретесь то? deadlocks у вас в базе при многопользовательской работе или что?

Борется за красоту кода