|
|
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
Пытаюсь с помощью CDatabase/CRecordset записать в таблицу MS SQL, а он мне говорит мол множество записей read only. Проверил тот же код на Access'е - все нормально. На базе R/О не стоит. Почему сие может происходить? Что где подкрутить надо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2002, 12:38:57 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
Первичный ключ есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2002, 12:40:05 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
А собственно при чем здесь первичный ключ??????? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2002, 13:58:58 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
не может без первичного ключа определить какую запись апдейтить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2002, 14:11:42 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
> блокировкис-с-с... Какие блокировки, я на ней (на базе) один сижу > не может без первичного ключа определить какую запись апдейтить Враки, все он может. Ключи не при чем. И кстати на R/O ругается и при AddNew(). А специально для Вас - сделал первичный ключ - результат тот же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2002, 15:06:47 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
Извиняюсь, все же действительно с ключем набор становится доступным для записи (все же непонятно, почему так...), но при апдейте ругается ("Ошибка при попытке обновления или удаления."), хотя и апдейтит (это то меня и сбило...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2002, 15:32:51 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
а как тогда быть, если primary key не нужен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2002, 17:07:37 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
если у вас в таблице две абсолютно одинаковые записи, то исправить только одну из них стандартными средствами не получиться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2002, 18:31:25 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
2AlexQC Как это primary key не нужен? А для удаления или обновления записи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2002, 19:16:10 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
Как бы это точнее выразиться... 1. Мне нужно скорее добавление чем изменение/удаление. 2. Записи такие, что 2х одинаковых быть не дОлжно. 3. В любом случае, если MS SQL не накладывает условие обязательности первичного ключа, значит должен с такими таблицами работать. 4. Конечно, можно какое-нибудь identity добавить, но зачем мне лишнее поле, если прямой необходимости в нем нету? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2002, 10:19:48 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
1. Мне нужно скорее добавление чем изменение/удаление. Рано или поздно придется что-то удалять - ведь не будет же ваша база расти до бесконечности. Кроме того, зачем держать в таблице данные, к которым никто не обращается по причине окончания какого-либо срока актульности 2. Записи такие, что 2х одинаковых быть не дОлжно. А вот этого как раз вы без первичного ключа (как ограничения для таблицы) не получите 3. В любом случае, если MS SQL не накладывает условие обязательности первичного ключа, значит должен с такими таблицами работать. MS SQL - не накладывает. В этом можно убедится, если попробуете изменить таблицу например через Enterprise Manager. А вот клиентское приложение запросто может. Потому как работает с таблицей через запрос (UPDATE/DELETE/INSERT) и поэтому не может при том же обновлении однозначно отличить одну запись от другой. 4. Конечно, можно какое-нибудь identity добавить, но зачем мне лишнее поле, если прямой необходимости в нем нету? Наличие полей типа первичного ключа определяется не желанием/нежеланием, а собственно самой теорией реляционных баз данных.(см. нормальные формы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2002, 10:55:57 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
2AlexQC учите матчасть :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2002, 11:45:17 |
|
||
|
Почему R/O?
|
|||
|---|---|---|---|
|
#18+
Встречный вопрос - если первичного ключа нет, то как клиент должен определять какую запись апдейтить? По полному соответствию всех полей? А если кто-нибудь изменил за это время какое-нибудь, это та же запись осталась или уже другая? Тут мы попадаем в область теории РБД. Не стОит туда лезть. Если у Вас двух одинаковых записей быть не дОлжно, то первичным ключом является полный набор всех полей (это будет естественный ключ) или можно добавить identity (это будет суррогатный). Делать же первичный ключ надо хотя бы и потому, что он автоматом делает кластерный индекс. Если Вы руками не делаете кластерный индекс, то физически записи лежат не очень хорошо - почитайте как оно. Да и индексы работают лучше с привязкой к кластерному индексу, а не к хеш-значению, которое используется в отсутствии оного. Так что делайте первичный ключ и избежите многих геморроев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2002, 12:12:43 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=32043204&tid=1821073]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
42ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 198ms |
| total: | 325ms |
| 0 / 0 |
