Здравствуйте, 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 изменений" не нужен, если заведомо известно, что объект неизменный. Краткое описание — туда же. Если оно действительно нужно для каких-то объектов, оно будет, но не в корне иерархии.

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

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

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

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

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

V>Смысл в том, что у разных объектов разные свойства, опциональные и т.п. Одинаковый "реальный смысл" для всех объектов может оказаться бессмысленным. Например, "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, но это довольно неприятно, таких таблиц всё-таки больше чем одна...