Можно ли узнать номер физической записи...

← →
Piter © (2004-08-05 17:17) [0]

в SQL базах?
Например, можно это сделать в Firebird, MSSQL?

← →
Sandman25 © (2004-08-05 17:18) [1]

Зачем?

← →
46_55_41_44 © (2004-08-05 17:19) [2]

AdoTable.RecNo
или
AdoQuery.RecNo

← →
sniknik © (2004-08-05 17:22) [3]

46_55_41_44 © (05.08.04 17:19) [2]
это будет номер в рекордсете. никакой информации по идентификации записи от запроса к запросу не несет.

← →
Johnmen © (2004-08-05 17:25) [4]

В IB/FB/YA можно узнать идентификатор "физической записи"...
А понятия "номер" не существует. Везде.

← →
Rule © (2004-08-05 17:29) [5]

Piter © (05.08.04 17:17)
Можно вставить рендом (как советовал АП) эфект будет тот же

← →
Piter © (2004-08-05 17:34) [6]

Johnmen © (05.08.04 17:25) [4]
В IB/FB/YA можно узнать идентификатор "физической записи"...

а он в общем тоже самое, что и номер записи, да? То есть, начинается с 1 (или там с 0) и продолжается далее. Или нет?

А как с этим дело обстоит в MSSQL?

← →
46_55_41_44 © (2004-08-05 17:42) [7]

> 46_55_41_44 © (05.08.04 17:19) [2]
> это будет номер в рекордсете. никакой информации по идентификации
> записи от запроса к запросу не несет.

Select * From Table1
Вот и все!
и RecNo будет нормально работать...
Но можно и без Query... С помощью TAdoTable.

← →
Johnmen © (2004-08-05 17:50) [8]

>Piter © (05.08.04 17:34) [6]

Нет. Он совсем другое...:)

← →
sniknik © (2004-08-05 18:05) [9]

> Вот и все!
не все, допустим ты сделал удаление в первых записях, что получится при следующем запросе? это разве правильная идентификация?
не говоря уже о том что порядок можно получить и просто ничего не делая (самому), а админ к примеру компакт базе сделал, добавил/сменил кластерный индекс, или MSSQL план поменял, и все, придет запрос в другой последовательности.

> Но можно и без Query... С помощью TAdoTable.
а запусти профайлер и посмотри что при открытии TAdoTable произойдет.

← →
Piter © (2004-08-05 18:34) [10]

Johnmen © (05.08.04 17:50) [8]
Нет. Он совсем другое...:)

ну а как? Это число или что? Как оно выбирается. какой диапазон имеет?

← →
s999 (2004-08-05 18:46) [11]

Ты бы объяснил, что у тебя за задача, зачем тебе это нужно, может чего посоветовали бы.

Johnmen имеет в виду dbkey. Он стабилен в рамках только одной транзакции, размер его зависит от числа таблиц в запросе, а работа с ним весьма нетривиальна. Поэтому лучше объясни.

← →
VID © (2004-08-05 19:06) [12]

Piter, обычно для получения уникального номера записи, создают поле "ID", куда при каждом добавлении новой записи, записывается значение генератора, который перед этим инкрементируется на 1. Это уникальное число и будет "удостоверением личности" записи в течении всей её жизни. Ни о каких RecordNumber в потомках TDataSet и думать не следут, если необходимо уникально идентифицировать запись.

← →
VID © (2004-08-05 19:08) [13]

VID © (05.08.04 19:06) [12]
забыл добавить, что само поле "ID" делают первичным ключем.

← →
Anatoly Podgoretsky © (2004-08-05 19:21) [14]

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

← →
}|{yk © (2004-08-05 19:25) [15]

Ну в Oracle можно использовать rowid, но они нестабильны могут быть

← →
Piter © (2004-08-05 19:45) [16]

s999 (05.08.04 18:46) [11]
Ты бы объяснил, что у тебя за задача

просто узнать...

← →
Piter © (2004-08-05 19:48) [17]

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

Использовалось какое-то служебное поле... $RBC или блин типа того...

Речь шла о Firebird

← →
VID © (2004-08-05 19:52) [18]

Вообще то при простом запросе
Select * from table1 записи упорядочеваются именно по физическому расположению в базе, это работа плана NATURAL.

← →
s999 (2004-08-05 20:03) [19]

> Использовалось какое-то служебное поле... $RBC или блин
> типа того...

Ну поиграйся, если хочешь. Делается это, например, так:

select TABLE.*, rdb$db_key from TABLE

← →
Piter © (2004-08-06 00:20) [20]

О! Так что такое rdb$db_key объясните плиз

← →
Sirus (2004-08-06 07:55) [21]

Это и есть идентификатор записи... для IB он для каждой записи как бы уникальный... потому что при попытке просмотра значения этого поля у всех записей значение получается одинаковое...
При помощи rdb$db_key можно удалять одинаковые (multiple) записи

← →
sniknik © (2004-08-06 08:19) [22]

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

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

← →
Rule © (2004-08-06 08:47) [23]

Вот процитирую из книги "Введение в Интербейз", написаной А. Я. Скляром:
"..... Порядок строк в таблице не фиксируется (таблица отражает отношение, которое яввляется множеством, а для элементов множества порядок не фиксируется). Таким образом таблица определяется составом поименованных столбцов вне зависимости от порядка их записи, а также составом строк вне зависимости от порядка их следования ..."
Это из главы "Реляционные базы данных" ...
Так что я думаю их этого можно сделать выводы ...

← →
s999 (2004-08-06 11:32) [24]

> не знаток IB, поэтому вопрос, что будет после бэкап & ресторе?
>

Какой "бэкап & ресторе"? Я же сказал: db_Key стабилен только в рамках одной транзакции. Это чисто технологическая вещь, использование клиентом черезвычайно редкое. Физически, это номера страниц со смещением в базе. Такое обращение к записи является наиболее быстрым из всех возможных, фактически, это прямое обращение. Пример использования... ну, можете посмотреть исходники IBTable.

← →
Johnmen © (2004-08-06 11:36) [25]

А что значит "db_Key стабилен только в рамках одной транзакции" ?

← →
s999 (2004-08-06 12:03) [26]

> А что значит "db_Key стабилен только в рамках одной транзакции"
> ?

А это и означает, что db_Key никакой не индентификатор записи, а всего-лишь текущее расположение этой записи в базе. Например:

IBTrans: TIBTransaction;
IBDataSet: TIBDataSet;
IBDataSet.SelectSQL = "select TABLE.*, rdb$db_key from TABLE"

IBTrans.StartTransaction;
IBDataSet.Open;

Допустим в TABLE одна запись.

Теперь, сколько угодно раз делаем IBDataSet.Open/Close;

всегда видим гарантированно одно и тоже уникальное значение в поле db_key.

А теперь:

IBTrans.CommitTransaction;
IBTrans.StartTransaction;
IBDataSet.Open;

А вот теперь можем увидеть и другое значение в поле db_key.

← →
Sirus (2004-08-06 12:09) [27]

s999 (06.08.04 12:03) [26]

А вот теперь можем увидеть и другое значение в поле db_key.

А как можно увидеть значение поля db_key???
дело в том что я сколько ни пытался в качестве значения я получал только один символ одинаковый для всех записей (визуально, так как distinct возвращает то же самое количество записей....)

>А это и означает, что db_Key никакой не индентификатор записи,
>а всего-лишь текущее расположение этой записи в базе.

1. Что значит "стабилен" ?
2. Можно как-то по-другому работать с БД, вне транзакций ?

← →
s999 (2004-08-06 12:36) [29]

> А как можно увидеть значение поля db_key???

"Глазами" различить вряд ли получится :) B IBX, например, используется (вариант одна таблица):

DBKey: array[0..7] of Byte;

Что там может показать контрол?

> 1. Что значит "стабилен" ?

Я как то непонятно объясняю? Это означает гарантированную неизменность значения db_Key.

> 2. Можно как-то по-другому работать с БД, вне транзакций
> ?

А это к чему?

s999 (06.08.04 12:03) [26]
"select TABLE.*, rdb$db_key from TABLE"

а у меня после выполнения запроса в поле бд_кей во всех записях высвечивается один и тот же символ "Ђ",вот так

>Я как то непонятно объясняю?

Ага.

>Это означает гарантированную неизменность значения db_Key.

+ уникальность уже есть.
Почему же нельзя считать его уникальным идентификатором ?

>А это к чему?

Да так, поинтересовался...:)

← →
s999 (2004-08-06 13:40) [32]

> а у меня после выполнения запроса в поле бд_кей во всех
> записях высвечивается один и тот же символ "Ђ",вот так

А что ты хочешь от набора байт в строковом предсталении :) Это все-равно что exe в текстовом редакторе открыть и изучать. Чтобы реально использовать dbkey надо попотеть.

> + уникальность уже есть.
> Почему же нельзя считать его уникальным идентификатором
> ?

Ну, например, классическое разделение на читающую/пишущую транзакцию уже может не пройти. Прочитали в read, пытаемся проапдейтить запись по dbkey в write. Можем получить облом. От абстрактного понятия "уникальный идентификатор записи" как то интуитивно ожидается несколько другое.

>Прочитали в read, пытаемся проапдейтить запись по dbkey в
>write. Можем получить облом.

Разговор шел только о чтении.

>От абстрактного
>понятия "уникальный идентификатор записи" как то интуитивно
>ожидается несколько другое.

Естественно.

s999 (06.08.04 13:40) [32]

Чтобы реально использовать dbkey надо попотеть.

А у Вы когдато потели над этим, если да то интересно было бы взглянуть ...

← →
s999 (2004-08-06 14:15) [35]

> А у Вы когдато потели над этим, если да то интересно было
> бы взглянуть ...

Достаточно посмотреть на "потение" Джефа :)

Открой IBTable.pas, IBCustomDataSet.pas. Ключевые слова для поиска и анализа:

"IBX_INTERNAL_DBKEY"
"RDB$DB_KEY"
TIBDBKey
DBKey
PIBDBKey

s999 (06.08.04 14:15) [35]
Спасибо, много интересного :)

Можно ли узнать номер физической записи... Найти похожие ветки