Коды ошибок провайдера.

← →
Bless © (2006-08-18 15:13) [0]

Где можно узнать перечень сабжей с текстовым описанием для SQL Server-а?
Может искать не умею, но поиск по MSDN ничего не дал.

← →
sniknik © (2006-08-18 15:19) [1]

BOL -> xxx (error)
где xxx цифра или период.

← →
Bless © (2006-08-18 15:28) [2]

> sniknik © (18.08.06 15:19) [1]

Это не подходит. Например, ошибку Row cannot be located for updating. Some values may have been changed since it was last read генерирует не sql-сервер, а провайдер, видимо.

← →
Bless © (2006-08-18 15:35) [3]

Собственно говоря меня интересует, как отловить эту самую
Row cannot be located for updating. Some values may have been changed since it was last read

Думаю приблизительно так
try q.post except on E: EDataBaseError do begin if q.connection.Errors.Count=1 then if q.connection.Errors[0].NativeError=32 then ...//тут типа отловил else raise; end; ... end;{try}

Но гнетут сомнения, а вдруг код 32 имеет еще какая-нибудь ошибка или на факт изменения записи в базе со времени моего запроса провайдер реагирует еще как-нибудь кроме Row cannot be located for updating. S

← →
Ega23 © (2006-08-18 15:37) [4]

> Собственно говоря меня интересует, как отловить эту самую
> Row cannot be located for updating. Some values may have
> been changed since it was last read

Транзакцию с соответствующим Isolation Level выставлять надо. И не будет таких ошибок.

← →
Bless © (2006-08-18 15:51) [5]

> Ega23 © (18.08.06 15:37) [4]
> Транзакцию с соответствующим Isolation Level выставлять
> надо. И не будет таких ошибок.

Этот вариант в данном случае мне не подходит. Высокий Isolation Level приведет к ненужным блокировкам.

← →
Ega23 © (2006-08-18 16:00) [6]

> Этот вариант в данном случае мне не подходит. Высокий Isolation
> Level приведет к ненужным блокировкам.

Тогда отдельную таблицу блокировок записей по разным клиентам.

← →
sniknik © (2006-08-18 16:07) [7]

указываеш тип обновлений по ключу. а не всей записи (Properties["Update Criteria"].Value:= adCriteriaKey, можно в "афтеропен" например )... мало того что ошибки не будет так еще и быстрее работать будет.

← →
Bless © (2006-08-18 16:11) [8]

> Ega23 © (18.08.06 16:00) [6]
>
> Тогда отдельную таблицу блокировок записей по разным клиентам.
>

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

← →
Ega23 © (2006-08-18 16:21) [9]

> скажи, как вы в этой таблице блокировок записей по разным
> клиентам отслеживаете факт отключения клиента (ну типа завис,
> поэтому занятые записи сам освободить не может, а жить
> дальше как-то надо)

У нас оператор - живой человек за клиентским АРМ-ом работает. Поэтому, когда запись заблокирована одним, то другой при попытке обратиться к ней (точнее - начать редактирование) получит мессадж, типа "Запись такая-то обрабатывается таким-то на таком-то АРМе". При старте программы все блокировки данного АРМа вычищаются (это если завис и не убрал сам).

> и что используется в качестве идентификатора клиента.

Список операторов храниться в БД: ФИО, логин, пароль (там сложнее, но это к делу не относится). Также есть таблица возможных АРМов. АРМ идентифицируется через IP (или сетевое имя, это как угодно). Оператор - через логин, пассворд и дату входа. Если данный оператор в данное время с данного АРМа работать не может - в газенваген.

В общих чертах так.

← →
Bless © (2006-08-18 16:28) [10]

> sniknik © (18.08.06 16:07) [7]
>
> указываеш тип обновлений по ключу. а не всей записи (Properties["Update
> Criteria"].Value:= adCriteriaKey, можно в "афтеропен" например
> )... мало того что ошибки не будет так еще и быстрее работать
> будет.
>

Можно и так, конечно. Но все же хотелось не записать изменения в базу в любом случае, а просто, раз уж я напоролся на измененную запись, перезапросить ее, чтоб была в актуальном состоянии.
Т.е. меня уставивает мой вариант в [3], где вместо
//тут типа отловил
будет что-то типа
q.Cancel; RefreshCurRec(q);//обновить текущую запись датасета

Просто хочу уверенности, что вариант q.connection.Errors[0].NativeError=32 - единсвенная реакция провайдера на измененные после меня данные.

← →
Bless © (2006-08-18 16:30) [11]

> АРМ идентифицируется через IP (или сетевое имя, это как
> угодно)

А как в TSQL получить IP-адрес?

← →
clickmaker © (2006-08-18 16:39) [12]

> А как в TSQL получить IP-адрес?

передать с клиента при логоне

← →
Bless © (2006-08-18 16:43) [13]

> clickmaker © (18.08.06 16:39) [12]>

А если клиент соврал с нехорошими целями?

← →
clickmaker © (2006-08-18 16:46) [14]

> А если клиент соврал с нехорошими целями?

в газенваген )

← →
Ega23 © (2006-08-18 16:51) [15]

> А если клиент соврал с нехорошими целями?

А как он соврёт? Клиент только логин-пассворд вводит, IP автоматом берётся.

← →
Bless © (2006-08-18 16:52) [16]

> clickmaker © (18.08.06 16:46) [14]
> в газенваген )

:)

← →
clickmaker © (2006-08-18 16:54) [17]

если по хорошему, то:
1. Клиентская прога должна работать под внутренним логином и паролем, который может не знать даже админ.
2. Доступ на запись к хранимкам и базе вообще не давать никому, кроме админа и этого логина
3. Идентификация пользователей АРМ должна решаться НЕ средствами SQL, а с помощью своих собственных логинов-паролей (хэшей)
4. Хранимки надо шифровать
5. Блокировки - на уровне АРМов, а не сиквельных уровней изоляции (ну это уже Ega сказал)

Тогда не будет нехороших клиентов с нехорошими целями )

← →
Ega23 © (2006-08-18 17:00) [18]

Согласен по всем пяти пунктам. Именно так у нас и построено. С первого по пятый.
Разве что ХП пока (но только пока) не шифруем, ибо откатка идёт. В финальном релизе всё зашифровано будет.

Да, я бы ещё один пункт добавил: никаких прямых Insert-Update-Delete-Select. Всё ТОЛЬКО через ХП.

← →
Bless © (2006-08-18 17:02) [19]

> Ega23 © (18.08.06 16:51) [15]
>
> А как он соврёт? Клиент только логин-пассворд вводит, IP
> автоматом берётся.

Т.е. как в [12]? IP-адрес формирует клиентская программа, передает его серверу, который уже с этим переданным IP-адресом работает?
А кто мешает мне, вредному юзеру с язвой желудка, написать своего клиента, но вместо своего IP-адреса посылать чужой.
Права, я так понимаю, у вас на логин/пароль даются, а не на IP, т.е. новых прав я не получу, но все блокировки, наложенные этим ip-адресом, если он сейчас параллельно работает, сниму (ты ж говорил, при старте программы все блокировки данного АРМа вычищаются). А это ж нехорошо.

← →
Bless © (2006-08-18 17:03) [20]

Bless © (18.08.06 17:02) [19]>

Впрочем, ладно, наверное я параноик.

← →
Bless © (2006-08-18 17:07) [21]

> Ega23 © (18.08.06 17:00) [18]
>
> Да, я бы ещё один пункт добавил: никаких прямых Insert-Update-
> Delete-Select. Всё ТОЛЬКО через ХП.

Замечательный пункт. Давно хотел об этом поговорить, да не с кем :)
У вас гриды есть? А изменять через них можно?
Если оба ответа "да", то как вы подсовываете ADODataset-у хранимку вместо сформированного им самим запроса. Или у вас ClientDataSet-ы кругом поверх ADODataSet-ов? Или... В ощем, как у вас?

PS отклонились от сабжа, ну и черт с ним, это интересней ;)

← →
Bless © (2006-08-18 17:13) [22]

> clickmaker © (18.08.06 16:54) [17]
>
> 1. Клиентская прога должна работать под внутренним логином
> и паролем, который может не знать даже админ.

Гм... А если, к примеру, им часто нужны разнообразные запросы для отчетов и я хочу дать им возможность делать select-ы из некоторых таблиц (но только select-ы!), к примеру поставив Query Analizer, то придется обломаться?
Или у вас отчетные возможности таковы, что покрывают все их фантазии?

← →
Bless © (2006-08-18 17:21) [23]

> При старте программы все блокировки данного АРМа вычищаются
> (это если завис и не убрал сам).

Кстати, а если АРМ завис, а пользователь решил воспользовать случаем и пошел кофе попить, пока машина перегружается.
А его блокировки так и остались, пока он в следующий раз программу не запустит? А если другой человек с этими записями поработать хочет, то придется ждать пока первый кофе допьет, вернется и запустит программу?

← →
Bless © (2006-08-18 17:22) [24]

Вот е-мое. Это ж в России рабочий день закончился. ;(

← →
Ega23 © (2006-08-18 17:22) [25]

> У вас гриды есть? А изменять через них можно?
> Если оба ответа "да", то как вы подсовываете ADODataset-
> у хранимку вместо сформированного им самим запроса. Или
> у вас ClientDataSet-ы кругом поверх ADODataSet-ов? Или..
> . В ощем, как у вас?
>

Гриды есть, только изменять из них нельзя. Вызывай модальный диалог, там все свойства данной сущности перечислены. Если всё-таки надо непременно из грида, то да, через CDS.
Просто в гриде зачастую очень трудно отобразить все поля сущности.

← →
Ega23 © (2006-08-18 17:24) [26]

> Кстати, а если АРМ завис, а пользователь решил воспользовать
> случаем и пошел кофе попить, пока машина перегружается.
> А его блокировки так и остались, пока он в следующий раз
> программу не запустит? А если другой человек с этими записями
> поработать хочет, то придется ждать пока первый кофе допьет,
> вернется и запустит программу?

В общем случае - да. Но за 5 лет работы на серьёзном объекте (бюро пропусков, предприятие > 12000 сотрудников), такое ни разу не случалось.

← →
Bless © (2006-08-18 17:47) [27]

> Ega23 © (18.08.06 17:22) [25]
>
> Если всё-таки надо непременно з грида, то да, через CDS.
>
>

Жаль :(

← →
Ega23 © (2006-08-18 17:54) [28]

> Жаль :(

Если база нормализована, то тебе очень редко придётся Select * делать. Чаще связывать по двум-трём-четырём и более таблицам запрос идёт. Как такое в гриде редактировать, я себе не представляю.

Ega23 © (18.08.06 17:54) [28]>

Ну, если нет group by, union и т.п. то несколько таблиц в запросе не мешают быть ему редактируемым в гриде.

Но даже если есть group by то можно было бы редактировать через грид, если подсунуть свои хранимки/запросы. Вот был бы как под BDE аналог TUpdateSQL...

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

> Это ж два варианта одних и тех же данных в памяти.
>

ПОЧЕМУ????

DataSet.Open;
CDS.Open;
DataSet.Close;
А данные в CDS остались.

> Ega23 © (18.08.06 18:09) [30]
>
>
> ПОЧЕМУ????
>
> DataSet.Open;
> CDS.Open;
> DataSet.Close;
> А данные в CDS остались.

Ну если Dataset.Close, то после этого их нет конечно. Но все-равно зачем копировать данные, которые уже есть, из одного места в другое только для того, чтоб нормально с ними поработать. Искал реализацию аналога UpdateSQL под ADO, но все какие-то корявые и глючные. Эх (мечтательно), если б можно было статус записи recordset-а менять...

> Эх (мечтательно), если б можно было статус записи recordset-
> а менять...
>

Открою секрет: можно. Не на уровне DataSet, конечно. Просто в выборку добавляешь RecordStatus int =0.
0 - без изменений. 1 - добавили новую. 2 - изменили существующую. 3- удалили существующую.
На Apply проходишь все <>0, а дальше - в соответствии что там у тебя: 1, 2 или 3.

> Ega23 © (18.08.06 18:48) [32]
> Открою секрет: можно. Не на уровне DataSet, конечно. Просто
> в выборку добавляешь RecordStatus int =0.

Только потом этот RecordStatus редактировать нельзя :) Или ты знаешь еще один секрет, как можно?

AdoDataset1.SaveToFile("tab.xml", pfXML); ...тут правим атрибуты readonly-колонки в файле tab.xml AdoDataset1.LoadFromFile("tab.xml"); за секрет не считается :)

Блин. Если тебе вот прям так сильно надо - ну добавь ещё один Column к CDS в рантайме после открытия. И редактируй его.
Просто по мне - так проще в Select добавить.

> Ega23 © (18.08.06 19:16) [34]
>
> Блин. Если тебе вот прям так сильно надо - ну добавь ещё
> один Column к CDS в рантайме после открытия. И редактируй
> его.
> Просто по мне - так проще в Select добавить.

Есть запрос
SELECT *, 0 AS RecordStatus FROM t1

Можешь кинуть пример с CDS, в котором можно было бы редактировать поле RecordStatus? Я с CDS серьезно не работал.

Можно и так, конечно. Но все же хотелось не записать изменения в базу в любом случае
Да как же ты запишешь, если например база не позволяет дубли или что то еще. С логикой не дружим?

clickmaker © (18.08.06 16:46) [14]
Автора подобной идеи, не тебя конечно, а кто дошел до такой глупой идеи, твое предложение верное.

Коды ошибок провайдера. Найти похожие ветки