| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Коды ошибок провайдера. [D7, MSSQL]
Bless © (2006-08-18 15:13:00)Где можно узнать перечень сабжей с текстовым описанием для SQL Server-а?
Может искать не умею, но поиск по MSDN ничего не дал.
Ega23 (2006-08-21 09:37:00) [1]
>
> Anatoly Podgoretsky © (18.08.06 23:35) [40]
>
> Ega23 © (18.08.06 16:51) [15]
> Не ужели ИП проблема?
>
Ты же сам говорил, что паранойя должна быть разумной?
Bless (2006-08-19 12:15:00) [2]
> А мне хочется так делать только в случае измененной кем-
> то другим записи в базе, во всем остальных случаях отказа
> просто показать ошибку.
В общем-то, потому и спрашиваю о кодах ошибок, чтоб посмотреть какие они вообще бывают.
А то если причины отказа update ограничиваются только двумя:
- кто-то после меня изменил
- нет прав на изменение.
то можно действительно сделать как в упомянутом примере на королевстве
Bless (2006-08-19 12:00:00) [3]
> sniknik © (19.08.06 10:17) [44]
Статьи про ADO c королевства я читал, хотя о варианте с adResyncConflicts забыл совсем.
Update Resync=adResyncConflicts не обновит мне значение полей в датасете автоматом. Это просто изменит UnderlyingValue у полей со старых на актуальные значения. А вот делать Value равное UnderlyingValue придется вручную. А где делать - это, имхо, дело вкуса. Я хочу в try-except, а не в обработчиках событий dataset-а, как в примере с королевства.
В таможнем примере использования adResyncConflicts стоит обработчик
> if Reason=erUndoUpdate then begin ///в случае ошибки
> ReadUnderlyingValues; //тут value := UnderlyingValue
> EventStatus:=esCancel; //....и прото отменяем обновление
> end;
>
Этот пример, имхо, полностью аналогичен моему:
try
q.post;
except
on E: Exceptiondo begin
q.Cancel;
RefreshCurRec(q);//обновить текущую запись датасета
end;
...
end;{try}
Т.е. вне зависимости от причины отказав update, в обеих примерах обновляется текущая запись до актуальных значений и отменяются изменения.
А мне хочется так делать только в случае измененной кем-то другим записи в базе, во всем остальных случаях отказа просто показать ошибку.
sniknik (2006-08-19 10:17:00) [4]а вообще посмотри на королевстве статьи по ADO, ты ямно не используеш его возможности, пытаешся реализовать сам то что уже есть...
sniknik (2006-08-19 10:09:00) [5]> а перехватить ошибку "такой записи больше нет", обновить запись на клиенте до состояния 2) и далее по обстоятельствам.
adResyncConflicts в параметре Update Resync по моему это делает автоматом (не уверен точно потому как не использовал, но по описаниям в хелпах), т.е. если произошол конфликт при записи то конфликтная строка считывается с сервера.
это к тому что не надо будет в ексепте это делать и делить на ошибки по кодам, в эксепте надо только учесть что ошибка была, сообшить ее юзеру, и пускай разбирается.
Bless (2006-08-19 09:16:00) [6]
> Anatoly Podgoretsky © (18.08.06 23:29) [36]
>
> Можно и так, конечно. Но все же хотелось не записать изменения
> в базу в любом случае
> Да как же ты запишешь, если например база не позволяет дубли
> или что то еще. С логикой не дружим?
К словам придираетесь? Разумеется, если в базе есть ограничения на значение записи, то оно не пройдет, несмотря ни на какие 'unique table'.
Пример:
пусть таблица имеет поля код наименование значение
----------------------------
1)
1 Киев город
Я выбрал эту запись к себе.
После этого кто-то изменил ее на такую
2)
1 Киев-град город
Я же решил изменить ее на такую:
3)
1 Киев мегаполис
Если воспользоваться советом sniknik[7], то никакой ошибки не возникнет,мое изменение пройдет, значение "город" изменится на "мегаполис", но у меня на клиенте останется "Киев", хотя в базе он уже "Киев-град". Так вот, я хочу не чтоб прошло мое изменение, а перехватить ошибку "такой записи больше нет", обновить запись на клиенте до состояния 2) и далее по обстоятельствам.
Anatoly Podgoretsky (2006-08-18 23:39:00) [7]Вопросы у тебя нормальные, но паранойя должна быть разумной и главное продуманной.
Anatoly Podgoretsky (2006-08-18 23:35:00) [8]Ega23 © (18.08.06 16:51) [15]
Не ужели ИП проблема?
Anatoly Podgoretsky (2006-08-18 23:34:00) [9]clickmaker © (18.08.06 16:46) [14]
Автора подобной идеи, не тебя конечно, а кто дошел до такой глупой идеи, твое предложение верное.
Anatoly Podgoretsky (2006-08-18 23:32:00) [10]Bless © (18.08.06 16:43) [13]
А если клиент соврал с нехорошими целями?
Тогда тебе не повезло.
Anatoly Podgoretsky (2006-08-18 23:31:00) [11]Bless © (18.08.06 16:30) [11]
А откуда возмется ИП если протокол отличен от TCP/IP
Anatoly Podgoretsky (2006-08-18 23:29:00) [12]Можно и так, конечно. Но все же хотелось не записать изменения в базу в любом случае
Да как же ты запишешь, если например база не позволяет дубли или что то еще. С логикой не дружим?
Bless (2006-08-18 19:45:00) [13]
> Ega23 © (18.08.06 19:16) [34]
>
> Блин. Если тебе вот прям так сильно надо - ну добавь ещё
> один Column к CDS в рантайме после открытия. И редактируй
> его.
> Просто по мне - так проще в Select добавить.
Есть запрос
SELECT *, 0 AS RecordStatus FROM t1
Можешь кинуть пример с CDS, в котором можно было бы редактировать поле RecordStatus? Я с CDS серьезно не работал.
Ega23 (2006-08-18 19:16:00) [14]Блин. Если тебе вот прям так сильно надо - ну добавь ещё один Column к CDS в рантайме после открытия. И редактируй его.
Просто по мне - так проще в Select добавить.
Bless (2006-08-18 19:07:00) [15]
> Ega23 © (18.08.06 18:48) [32]
> Открою секрет: можно. Не на уровне DataSet, конечно. Просто
> в выборку добавляешь RecordStatus int =0.
Только потом этот RecordStatus редактировать нельзя :) Или ты знаешь еще один секрет, как можно?
AdoDataset1.SaveToFile('tab.xml', pfXML);за секрет не считается :)
...тут правим атрибуты readonly-колонки в файле tab.xml
AdoDataset1.LoadFromFile('tab.xml');
Ega23 (2006-08-18 18:48:00) [16]
> Эх (мечтательно), если б можно было статус записи recordset-
> а менять...
>
Открою секрет: можно. Не на уровне DataSet, конечно. Просто в выборку добавляешь RecordStatus int =0.
0 - без изменений. 1 - добавили новую. 2 - изменили существующую. 3- удалили существующую.
На Apply проходишь все <>0, а дальше - в соответствии что там у тебя: 1, 2 или 3.
Bless (2006-08-18 18:32:00) [17]
> Ega23 © (18.08.06 18:09) [30]
>
>
> ПОЧЕМУ????
>
> DataSet.Open;
> CDS.Open;
> DataSet.Close;
> А данные в CDS остались.
Ну если Dataset.Close, то после этого их нет конечно. Но все-равно зачем копировать данные, которые уже есть, из одного места в другое только для того, чтоб нормально с ними поработать. Искал реализацию аналога UpdateSQL под ADO, но все какие-то корявые и глючные. Эх (мечтательно), если б можно было статус записи recordset-а менять...
Ega23 (2006-08-18 18:09:00) [18]
> Это ж два варианта одних и тех же данных в памяти.
>
ПОЧЕМУ????
DataSet.Open;
CDS.Open;
DataSet.Close;
А данные в CDS остались.
Bless (2006-08-18 18:04:00) [19]Ega23 © (18.08.06 17:54) [28]>
Ну, если нет group by, union и т.п. то несколько таблиц в запросе не мешают быть ему редактируемым в гриде.
Но даже если есть group by то можно было бы редактировать через грид, если подсунуть свои хранимки/запросы. Вот был бы как под BDE аналог TUpdateSQL...
Просто очень часто редактировать в гриде пользователям удобнее, чем в модальных диалогах. Можно, конечно, обойтись и TClientDataset, но эта идея мне не нравится как-то чисто идеологически. Это ж два варианта одних и тех же данных в памяти.
Ega23 (2006-08-18 17:54:00) [20]
> Жаль :(
Если база нормализована, то тебе очень редко придётся Select * делать. Чаще связывать по двум-трём-четырём и более таблицам запрос идёт. Как такое в гриде редактировать, я себе не представляю.
| |
Страницы: 