Здравствуйте, valker, Вы писали:

INSERT INTO qqq ( qqq )
SELECT max(qqq)+1
FROM qqq;

Но зачем ему тогда быть счетчиком?

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

Здравствуйте, valker, Вы писали:

V>Если есть другой способ узнавать новый ID, то было бы интересно узнать о нём.

А вот для этого тебе и придется отказаться от аксеса.

Здравствуйте, OLEGus1, Вы писали:

OLE>Вопрос был поставлен именно про аксес. При чем тут фаербед?

Да я как бы в курсе. Я просто предложил несколько иное решение, поскольку в рамках озвученного задача решения не имеет. Ну не понимает акцесс выражения DEFAULT VALUE, хотя и должен бы по соображениям совместимости с сиквелом.

Здравствуйте, valker, Вы писали:

V>Смысл в том, что у разных объектов разные свойства, опциональные и т.п. Одинаковый "реальный смысл" для всех объектов может оказаться бессмысленным. Например, "timestamp изменений" не нужен, если заведомо известно, что объект неизменный. Краткое описание — туда же. Если оно действительно нужно для каких-то объектов, оно будет, но не в корне иерархии.

Ясно... Однако, я бы посоветовал все же сменить движок БД. В том же Firebird можно сделать один единственный генератор и дергать его всякий раз при добавлении записей в таблицы. А поскольку генератор будет один, то и уникальность ID, им выданных, будет 100%-ой во всей БД.

Здравствуйте, valker, Вы писали:

V>Смысл в том, что у разных объектов разные свойства, опциональные и т.п. Одинаковый "реальный смысл" для всех объектов может оказаться бессмысленным. Например, "timestamp изменений" не нужен, если заведомо известно, что объект неизменный. Краткое описание — туда же. Если оно действительно нужно для каких-то объектов, оно будет, но не в корне иерархии.

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

Здравствуйте, valker, Вы писали:

V>Уникально различать объекты я буду по идентификатору. Признаков у объекта может и не быть (а может будут, но такие, что данная версия программы с ними не работает).

V>Структура базы такая:

V>

V>Таблица Item. 
V>Поля: 
V>    ItemID        : целое, дублирование запрещено

V>Таблица IntegerProperty. 
V>Поля:
V>    ItemID        : объект, которому принадлежит свойство
V>    PropertyID    : идентификатор конкретного свойства.
V>    PropertyValue : значение свойства
V>

Все равно непонятно, на кой нужна таблица, содержащая уникальные идентификаторы и ничего более? ИМХО, поскольку она не несет никакой смысловой нагрузки, ее можно смело исключить вообще. И генерировать уникальные ID непосредственно на клиенте, если уж так хочется использовать непременно Access. Потому как, исходя из структуры таблицы IntegerProperty, совершенно неясно, какому объекту принадлежат эти свойства. И, если уж так жизненно важно использовать таблицу Item, тогда сделай в ней описание объекта, например, его наименование. И все будет тогда работать.

Здравствуйте, valker, Вы писали:

V>Здравствуйте, FreeBeer, Вы писали:


V>Уникально различать объекты я буду по идентификатору. Признаков у объекта может и не быть (а может будут, но такие, что данная версия программы с ними не работает).
Предельный случай: имеем два объекта. Признаков у обоих нет, в понимании генерирующего они не эквивалентны (Нпр. собачка и кошечка у которых ножки отрезали, если брать пример с ножками).

<IMHO>
То что у Вас создано — нормальная система справочников, позволяющая построить достаточно гибко изменяемую систему. Но голый синтетический идентификатор без каких-либо дополнительных признаков(нпр. время появления в системе) недостаточен для идентификации объекта с объектом/событием реального мира.
</IMHO>

Здравствуйте!

В Microsoft Access создал таблицу:

Имя поля: ItemID
Тип данных: Счётчик

Пытаюсь при помощи ADO.NET создать записи в этой таблице.

Dim dbCmd As DbCommand = connection_.CreateCommand()
dbCmd.CommandText = "INSERT INTO Item"
dbCmd.ExecuteNonQuery()

Получаю исключение — "Syntax error in INSERT INTO statement."

Пробовал добавлять имя поля, слово "VALUES" и расставлять скобочки — не помогает.

Подскажите пожалуйта верный путь?

Заранее спасибо.

Здравствуйте, valker, Вы писали:

RTFM синтаксис оператора INSERT:

INSERT INTO MyTable (Item) Values (value)

INSERT INTO MyTable (Field1, Field2.... FieldN) Values (value1, value2 ... valueN)

Здравствуйте, Пацак,

Спасибо за ответ.

Но тема не закрыта. Вопрос был в том, что если у таблицы есть только одно поле — у которого автоинкрементирующийся тип, то что нужно писать в скобочках "VALUES (???)"

Заранее спасибо.

Здравствуйте, valker, Вы писали:

V>Здравствуйте, Пацак,

V>Спасибо за ответ.

V>Но тема не закрыта. Вопрос был в том, что если у таблицы есть только одно поле — у которого автоинкрементирующийся тип, то что нужно писать в скобочках "VALUES (???)"

V>Заранее спасибо.


По меньшей мере, оригинально.
А, если не секрет, зачем такая таблица?

Здравствуйте, OLEGus1, Вы писали:

OLE>По меньшей мере, оригинально.
OLE>А, если не секрет, зачем такая таблица?

Своего рода корень иерархии в ОО программировании. Общее свойство у всех объектов — это уникальность — для этого и нужна указанная таблица. Отклонения в свойсвах фиксируются в связанных таблицах, содержащие дополнительные и опциональные свойства.

Но всё-таки хотелось бы услышать ответ на поставленный вопрос:
Как вставить в таблицу новую запись, если единственное поле таблицы — автоинкрементирующийся счётчик?

Заранее спасибо.

Здравствуйте, valker, Вы писали:

1.
Single-record append query:

INSERT INTO target [(field1[, field2[, ...]])]
VALUES (value1[, value2[, ...])

2.

If you append records to a table with an AutoNumber field and you want to renumber the appended records, do not include the AutoNumber field in your query. Do include the AutoNumber field in the query if you want to retain the original values from the field.

insert [tbl] values (default)

Здравствуйте, valker, Вы писали:

V>Но тема не закрыта. Вопрос был в том, что если у таблицы есть только одно поле — у которого автоинкрементирующийся тип, то что нужно писать в скобочках "VALUES (???)"

Затем, что синтаксис такой. Можно (и то не уверен, что в Access прокатит) не писать список полей, а вот список значений — обязателен.

Здравствуйте, gavrilenko_s, Вы писали:

_>

_>insert [tbl] values (default)
_>

И что в итоге? Спросит что такое default? (Access 2002)

V>Своего рода корень иерархии в ОО программировании. Общее свойство у всех объектов — это уникальность — для этого и нужна указанная таблица. Отклонения в свойсвах фиксируются в связанных таблицах, содержащие дополнительные и опциональные свойства.

Стандартный INSERT того, что ты спрашиваешь, не умеет.

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

Оформи создание такой записи в хранимую процедуру, идентификатор получай в ней же.

Здравствуйте, Igor Trofimov, Вы писали:

iT>Оставляя в стороне вопрос целесообразности такой структуры, хочется заметить, что общих свойство должно быть существенно больше — реальный тип объекта, какое-нибудь время создания, код пользователя-создателя, возможно версия записи (для оптимистичных блокировок).
Оставляя ли?

iT>Оформи создание такой записи в хранимую процедуру, идентификатор получай в ней же.
На Аксесе?

OLE>Оставляя ли?

Оставляя.

iT>>Оформи создание такой записи в хранимую процедуру, идентификатор получай в ней же.
OLE>На Аксесе?

oops

Здравствуйте, Igor Trofimov, Вы писали:

iT>Оставляя.

Ты же предлагаешь добавить поле (это и есть изменение структуры). Тогда инсерт и дурак сделает. А вот в текущей ситуации что человеку делать?

Здравствуйте, OLEGus1, Вы писали:

OLE>Ты же предлагаешь добавить поле (это и есть изменение структуры). Тогда инсерт и дурак сделает. А вот в текущей ситуации что человеку делать?

Например, не использовать Access. Взять что-то более адекватное, умеющее работать с процедурами/триггерами. Тогда и вопрос об INSERT-ах отпадет сам собой. Если надо что-то компактное и переносимое, то Firebird Embedded.

Здравствуйте, Horror_Infinity, Вы писали:

H_I>Например, не использовать Access. Взять что-то более адекватное, умеющее работать с процедурами/триггерами. Тогда и вопрос об INSERT-ах отпадет сам собой. Если надо что-то компактное и переносимое, то Firebird Embedded.

Вопрос был поставлен именно про аксес. При чем тут фаербед?

Здравствуйте, OLEGus1, Вы писали:

OLE>Вопрос был поставлен именно про аксес. При чем тут фаербед?

Олег, а ты сам-то ответ знаешь или просто докапываешься? Я вот тут покумекал слегка и сдается мне при соблюдении всех исходных условий (INSERT, одно поле, автоинкремент, MS аксекс) задача решения не имеет. Или все-таки имеет?

Здравствуйте, Пацак, Вы писали:

П>Олег, а ты сам-то ответ знаешь или просто докапываешься? Я вот тут покумекал слегка и сдается мне при соблюдении всех исходных условий (INSERT, одно поле, автоинкремент, MS аксекс) задача решения не имеет. Или все-таки имеет?

В том то и дело, что не имеет.
А прикопался я из-за минуса. Непонятно за что.

Здравствуйте, Пацак, Вы писали:

П>Я вот тут покумекал слегка и сдается мне при соблюдении всех исходных условий (INSERT, одно поле, автоинкремент, MS аксекс) задача решения не имеет. Или все-таки имеет?

Интересно еще, что и в самом Аксессе Вставить такую запись не удается.

Здравствуйте, valker, Вы писали:

V>Но тема не закрыта. Вопрос был в том, что если у таблицы есть только одно поле — у которого автоинкрементирующийся тип, то что нужно писать в скобочках "VALUES (???)"

1. добавить еще одно поле, если минимум места — то bit, или можно информативное например DateTime(когда добавили)

create table [tba] ([id] integer identity(1,1), [e] bit)

insert into [tba] ([e]) values(1);

2 юзать vba

create table [tba] ([id] integer identity(1,1))

Sub addd()
    Dim rst As DAO.Recordset
    Set rst = CurrentDb.OpenRecordset("tba")
    rst.AddNew
    rst.Update
        rst.Close()
End Sub

Здравствуйте, wildwind, Вы писали:

W>Интересно еще, что и в самом Аксессе Вставить такую запись не удается.

Создал в Access XP две таблицы: одну только с Identity полем,
вторую с простым int полем. Добавил во вторую таблцу несколько записей.
Скопировал их в буфер обмена. Вставил во вторую таблицу.
Вместо скопированных значений отобразились 1, 2, 3, 4 (как и должно было быть).
Так что Access как-то это умеет делать. хм...

Здравствуйте, Ilya10k, Вы писали:

I>Создал в Access XP две таблицы: одну только с Identity полем,
I>...
I>Так что Access как-то это умеет делать. хм...

В Access 2000 тоже срабатывает, но это ж извращение!
Возможно сработает способ retn №2, только через ADO.

Здравствуйте, valker, Вы писали:

V>Но всё-таки хотелось бы услышать ответ на поставленный вопрос:
V>Как вставить в таблицу новую запись, если единственное поле таблицы — автоинкрементирующийся счётчик?

V>Заранее спасибо.

Могу ошибаться, но где то на этом форуме уже проскакивало, что
вставка в таблицу, содержащуюю только дефолтные параметры
используюя DML опреаторы
не реализуюема чуть ли не во всех БД.

Извините если наврал

Здравствуйте, valker, Вы писали:

V>Здравствуйте!

V>В Microsoft Access создал таблицу:

V>Имя поля: ItemID
V>Тип данных: Счётчик

V>Пытаюсь при помощи ADO.NET создать записи в этой таблице.

INSERT INTO Таблица1 ( ItemID)
SELECT Max(Таблица1.ItemID)+1 FROM Таблица1;

Правдо, корявый это путь

Здравствуйте, FreeBeer, Вы писали:

FB>Здравствуйте, valker, Вы писали:

V>>Здравствуйте!

V>>В Microsoft Access создал таблицу:

V>>Имя поля: ItemID
V>>Тип данных: Счётчик

V>>Пытаюсь при помощи ADO.NET создать записи в этой таблице.


FB>

FB>INSERT INTO Таблица1 ( ItemID)
FB>SELECT Max(Таблица1.ItemID)+1 FROM Таблица1;
FB>

FB>Правдо, корявый это путь

и со счетчиком работать не будет

Здравствуйте, tarasich, Вы писали:

T>и со счетчиком работать не будет
А Вы попробуйте...

Здравствуйте, FreeBeer, Вы писали:

FB>Здравствуйте, tarasich, Вы писали:

T>>и со счетчиком работать не будет
FB>А Вы попробуйте...

Оно-то работает... Вот только поле типа IDENTITY теряет всякий смысл, ибо акцесс послушно вставляет в него то, что мы ему скажем. И, если написать

INSERT INTO Таблица1 ( ItemID)
SELECT Max(Таблица1.ItemID)+100 FROM Таблица1;

то он и будет вставлять значения с шагом 100. А это не есть гуд.

T>вставка в таблицу, содержащуюю только дефолтные параметры
T>используюя DML опреаторы
T>не реализуюема чуть ли не во всех БД.


Кстати, а на пустые скобки полей и значений что скажет, syntax error ?

Здравствуйте, Horror_Infinity, Вы писали:

H_I>Оно-то работает... Вот только поле типа IDENTITY теряет всякий смысл, ибо акцесс послушно вставляет в него то, что мы ему скажем.

H_I>то он и будет вставлять значения с шагом 100. А это не есть гуд.

Шагать само оно не будет, но и значение меньше максимального оно добавить не сможет(констрейт, видать).
Те, то же самое идентити реализуется запросом на вставку.
Единственно, что меня смущает в данной конструкции — как оно будет жить при многопользовательской работе — с ходу предсказать не берусь.

Однако сакральный смысл такой таблицы для меня остается загадкой-счетчик не может быть объектом реального мира(IMHO).
А если так, то данный теоретический изыск практического применения иметь не должен...

Здравствуйте, FreeBeer, Вы писали:

FB>Однако сакральный смысл такой таблицы для меня остается загадкой-счетчик не может быть объектом реального мира(IMHO).
FB>А если так, то данный теоретический изыск практического применения иметь не должен...

Эта таблица хранит нечто общее для всех объектов, а именно признак их уникальности. Другие свойства объектов "реального мира" представлены в других таблицах.

Здравствуйте, FreeBeer, Вы писали:

FB>Правдо, корявый это путь

Мне за это путь минусов налепили

Здравствуйте, valker, Вы писали:

V>Эта таблица хранит нечто общее для всех объектов, а именно признак их уникальности. Другие свойства объектов "реального мира" представлены в других таблицах.

А смысл?! Какой в этом смысл — хранить айдюки объектов сами по себе, а их свойства — в других таблицах? Не проще ли к такому "уникальному" полю действительно приписать еще одно, с реальным смыслом? Например, кратким описанием объекта или писать в него timestamp изменений объекта? Как, например, советовал retn здесь

Автор: retn
Дата: 10.01.06

?

Здравствуйте, Horror_Infinity, Вы писали:

H_I>А смысл?! Какой в этом смысл — хранить айдюки объектов сами по себе, а их свойства — в других таблицах? Не проще ли к такому "уникальному" полю действительно приписать еще одно, с реальным смыслом? Например, кратким описанием объекта или писать в него timestamp изменений объекта? Как, например, советовал retn здесь

Автор: retn
Дата: 10.01.06

?

Смысл в том, что у разных объектов разные свойства, опциональные и т.п. Одинаковый "реальный смысл" для всех объектов может оказаться бессмысленным. Например, "timestamp изменений" не нужен, если заведомо известно, что объект неизменный. Краткое описание — туда же. Если оно действительно нужно для каких-то объектов, оно будет, но не в корне иерархии.

Спасибо за внимание.

Здравствуйте, wildwind, Вы писали:

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

Насколько я понял, автор реализует список объектов, участвующих в пъянке (а ля номер лицевого счета). Таким образом , по жизни, ему нужно обыкновенное индексированное поле без дублирующихся записей и генератор(сиквенс) последовательности чисел-идентификаторов. Эту задачу автор пытается решить за счет одного поля-счетчика.
На акцессе данную задачу можно решить либо в два прихлопа (монопольно открываемая база с очередным номером->запрос на получение текущего номера->вычисление нового номера->изменение текущего номера в базе->закрытие базы = решается через ADO/DAO либо через создание UDF) либо в один притоп — генерится guid на клиенте и инсертится в базу.

Однако у меня имеется чисто теоретический вопрос к автору. Как он будет уникально различать объекты, если к данному идентификатору не будет привязано ни одного признака?

Здравствуйте, FreeBeer, Вы писали:

FB>Здравствуйте, wildwind, Вы писали:

FB>Однако у меня имеется чисто теоретический вопрос к автору. Как он будет уникально различать объекты, если к данному идентификатору не будет привязано ни одного признака?

Уникально различать объекты я буду по идентификатору. Признаков у объекта может и не быть (а может будут, но такие, что данная версия программы с ними не работает).

Структура базы такая:

Таблица Item. 
Поля: 
    ItemID        : целое, дублирование запрещено

Таблица IntegerProperty. 
Поля:
    ItemID        : объект, которому принадлежит свойство
    PropertyID    : идентификатор конкретного свойства.
    PropertyValue : значение свойства

Приведу пример:
1. Создаём объект "человек".
1.1. Создаём новый уникальный объект, допустим идентификатор "1",
1.2. Создеём свойство объекта "число ног" со значением "2",
2. Создаём объект "собака".
2.1. Создаём новый уникальный объект, допустим идентификатор "2",
2.2. Создеём свойство объекта "число ног" со значением "4",
На данный момент в базе 2 объекта: "человек" и "собака" и их свойства — количества ног
Примеры запросов:
1. Найди объект у которого больше всего ног
2. Найди среднее число ног среди всех объектов

В такой формулировке структура базы не оптимальна. Но!
3. Создаём объект "амёба", идентификатор "3".
Ног у него нету, поэтому свойство "число ног" тоже не будем создавать.
Теперь запрос может формулироваться так:
3. Найди среднее число ног среди объектов, имеющих ноги.

Здравствуйте, valker, Вы писали:

V>Структура базы такая:

V>

V>Таблица Item. 
V>Поля: 
V>    ItemID        : целое, дублирование запрещено
      Name          : наименование объекта

V>Таблица IntegerProperty. 
V>Поля:
V>    ItemID        : объект, которому принадлежит свойство
V>    PropertyID    : идентификатор конкретного свойства.
V>    PropertyValue : значение свойства
V>

Здравствуйте, wildwind, Вы писали:

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

Согласен. Но! Как мне в таком случае уникально идентифицировать объекты?
Запрос "SELECT" к этой таблице на данный момент выполняется только один раз — для поиска подходящего ID для вновь создаваемого объекта.
Если есть другой способ узнавать новый ID, то было бы интересно узнать о нём.
Как вариант можно просмотреть все таблицы свойств, в поисках максимальных используемых ID, но это довольно неприятно, таких таблиц всё-таки больше чем одна...

Здравствуйте, valker, Вы писали:

V>Согласен. Но! Как мне в таком случае уникально идентифицировать объекты?
V>Запрос "SELECT" к этой таблице на данный момент выполняется только один раз — для поиска подходящего ID для вновь создаваемого объекта.
V>Если есть другой способ узнавать новый ID, то было бы интересно узнать о нём.
V>Как вариант можно просмотреть все таблицы свойств, в поисках максимальных используемых ID, но это довольно неприятно, таких таблиц всё-таки больше чем одна...

Как вариант — отказаться от акцесса и использовать более подходящую СУБД, позволяющую использовать уникальные последовательности в пределах всей структуры базы, например, Oracle или Firebird. В первом случае у тебя будет один единственный SEQUENCE, однозначно идентифицирующий все создаваемые объекты. Во втором слечае это будет генератор, выполняющий ровно те же самые функции. И дергай их на здоровье при добавлении в систему нового объекта.

Здравствуйте, Horror_Infinity, Вы писали:

H_I>например, Oracle или Firebird.
А также, множество других, имеющих в составе последовательности.

В аксесе это обойти, в принципе можно, но не нужно.
Создай рабочую табличку sequence и храни счетчики там. Но вся работа по их обновлению ляжет на тебя. А тебе оно надо?

Здравствуйте, OLEGus1, Вы писали:

H_I>>например, Oracle или Firebird.
OLE>А также, множество других, имеющих в составе последовательности.
Именно!..

OLE>В аксесе это обойти, в принципе можно, но не нужно.
OLE>Создай рабочую табличку sequence и храни счетчики там. Но вся работа по их обновлению ляжет на тебя. А тебе оно надо?
Мне — не сплющилось... Я таким извратом не страдаю. Если мне надо применить сквозную нумерацию объектов, я ее применяю. Правда, я не юзаю акцесс. Как-то привык ораклом обходиться.

H_I> Oracle или Firebird. В первом случае у тебя будет один единственный SEQUENCE, однозначно идентифицирующий все создаваемые объекты. Во втором слечае это будет генератор,

Уже и sequence тоже

А как в Access'e с тразнакциями ? Почему просто не сделать таблицу
Counter (integer id pk, integer value)
И считать что update Counter set value=1+value where id=0 && Select value where id=0 — это аналог sequence ?

Здравствуйте, Arioch2, Вы писали:

A>А как в Access'e с тразнакциями ? Почему просто не сделать таблицу
A>Counter (integer id pk, integer value)
A>И считать что update Counter set value=1+value where id=0 && Select value where id=0 — это аналог sequence ?

Конфликты будут наверное. Или баги, в зависимости от...

Здравствуйте, Arioch2, Вы писали:


H_I>> Oracle или Firebird. В первом случае у тебя будет один единственный SEQUENCE, однозначно идентифицирующий все создаваемые объекты. Во втором слечае это будет генератор,

A>Уже и sequence тоже
Это в двойке? Не знал, не знал... Надо будет скачать, поглядеть... Отстал я от жизни со своим ораклом.

A>А как в Access'e с тразнакциями ? Почему просто не сделать таблицу
A>Counter (integer id pk, integer value)
A>И считать что update Counter set value=1+value where id=0 && Select value where id=0 — это аналог sequence ?

Можно. А как это будет в многопользовательской среде? ИМХО, конфликты возникнут. Да и какова будет скорость отдачи значения этим селектом? Смотреть надо, однако...

Здравствуйте, Horror_Infinity, Вы писали:

A>>Уже и sequence тоже
H_I>Это в двойке? Не знал, не знал... Надо будет скачать, поглядеть... Отстал я от жизни со своим ораклом.


Ну а какая разница? Синтаксиси сиквенсов даже более ограничен — легче воспроизводим.

http://64.233.183.104/search?q=cache:HT8BTcX21AEJ:www.ibase.ru/firebird/fb2alpha01_rn_0200_02.pdf+sequence+generator+firebird&amp;hl=ru

Насчёт ACCESS незнаю, но вот в MySql
в это поле можно NULL вставлять.

mysql> CREATE TABLE tst (Id INT AUTO_INCREMENT, PRIMARY KEY(Id));
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO tst VALUES(NULL);
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM tst;
+----+
| Id |
+----+
|  1 |
+----+
1 row in set (0.03 sec)

mysql>

Здравствуйте, MishaSt, Вы писали:

mysql>> INSERT INTO tst VALUES(NULL);
MS>Query OK, 1 row affected (0.00 sec)

не. не хляет