Значение

← →
dima123 (2006-11-15 23:16) [0]

Заранее извиняюсь за глупый вопрос, я просто никогда вплотуную не работал с базами. Существует ли метод у ADODataSet, который по номеру строки и названию поля возвращает информацию из ячейки базы. Если да, то какой?
Спасибо.

← →
Percent (2006-11-15 23:33) [1]

Существует ли метод у ADODataSet, который по номеру строки и названию поля возвращает информацию из ячейки базы.

У строк в БД не бывает номеров.
Хотя, "номером строки" можно назвать значение первичного индекса.
Кроме того, в базе даннфх нет понятия "ячейки".
Рекомендую почитать литературу по основам построения БД: про таблицы, поля и пр.

В общем случае, получить то, что ты хочешь, можно запросом:

SELECT
[Field1Name], {[Field2Name], ... [FieldNName]}
FROM
[Table]
WHERE
([Field] = :Value) {OR\AND (AnotherCondition)}

Например,

SELECT
[FirstName]
FROM
[MyUsers]
WHERE
([LastName] = "Иванов")

При этом из таблицы [MyUsers] будут выбраны все записи, у которых в поле "LastName" = "Иванов".
Если "LastName" - первичный ключ, то будет выбрана одна или не выбрана ни одна (если в БД нету) запись.
Единственное поле в результирующем наборе данных - "FirstName".

← →
MikePetrichenko © (2006-11-15 23:49) [2]

> У строк в БД не бывает номеров.

Ошибочка. Oracel имеет внутренний идентификатор (уникальный) для каждой строки таблицы.
Как ни странно, FB его тоже имеет (где-то даже приводился пример как его получить).

← →
DrPass © (2006-11-15 23:54) [3]

> MikePetrichenko © (15.11.06 23:49) [2]

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

← →
MikePetrichenko © (2006-11-16 00:04) [4]

> Для идентификации записи необходимо использовать только
> лишь первичный ключ.

Это уже второй вопрос.
Я лишь опроверг категоричное утверждение

> У строк в БД не бывает номеров.

P.S. Сам Oracle рекомендует использовать (и широко использует сам) этот внутренний идентификатор (GUID кстати). Так что не нужно так категорично утверждать. Есть теория, а есть и практика работы определнных серверов. Все что можно утверждать в данном случае, это то, что, скажем, MS SQL не имеет идентификаторов строк (хотя сомневаюсь, так как не спец в MS SQL) за исключением пользовательских ID.

← →
DrPass © (2006-11-16 00:10) [5]

> Сам Oracle рекомендует использовать (и широко использует
> сам) этот внутренний идентификатор (GUID кстати).

Ну так GUID - это ведь не номер строки. Это просто суррогатный первичный ключ

← →
MikePetrichenko © (2006-11-16 00:55) [6]

> Ну так GUID - это ведь не номер строки. Это просто суррогатный
> первичный ключ

Это именно НОМЕР СТРОКИ. Блин, прочти мануал по Oracle и не спорь.

← →
DrPass © (2006-11-16 01:06) [7]

> MikePetrichenko © (16.11.06 00:55) [6]

Прочитал. Ты, видимо, имел в виду ROWID. Так вот, я тебя огорчу - это не номер строки, и уж тем более не GUID. Да, это идентификатор записи, суррогатный первичный ключ. Прочти мануал сам, что ли...

← →
MikePetrichenko © (2006-11-16 01:11) [8]

> Прочитал. Ты, видимо, имел в виду ROWID

Ошибочка вышла. ROWID актуален для готового запроса (курсора). Чтим внимательнее.

← →
Sergey13 © (2006-11-16 09:44) [9]

> [7] DrPass © (16.11.06 01:06)
> это идентификатор записи, суррогатный первичный ключ.
Не суррогатный. В нем содержится полный адрес записи в БД, включая табличное пространство, файл, экстент и т.д.
Именно поэтому на него нельзя ссылаться в связях, т.к. он может изменяться при импорте/экспорте например.

> [8] MikePetrichenko © (16.11.06 01:11)
Непонятно, про что ты пишешь.

← →
StriderMan © (2006-11-16 09:57) [10]

есть еще TDataSet.RecNo, но его использовать тока в крайних случаях.

← →
Anatoly Podgoretsky © (2006-11-16 10:00) [11]

> Непонятно, про что ты пишешь.

Он говорит, что это действительно для курсора.

← →
Sergey13 © (2006-11-16 10:12) [12]

> [11] Anatoly Podgoretsky © (16.11.06 10:00)

Я не понял про какой вообще номер строки (тем более GUID) он говорит, если не про ROWID.

← →
Anatoly Podgoretsky © (2006-11-16 10:20) [13]

> Sergey13 (16.11.2006 10:12:12) [12]

> Я не понял про какой вообще номер строки (тем более GUID) он говорит, если не про ROWID.

Он так не говорил, он не так говорил, сравни

> это даже не GUID

Говорил он про ROWID
Но даже для курсора не гарантируется стабильность, я подробности не помню, но одно время народ в конференциях жаловался.

← →
ANB © (2006-11-16 10:25) [14]

> MikePetrichenko © (16.11.06 01:11) [8]

> DrPass © (16.11.06 01:06) [7]

Спорите ни о чем. Поменьше категоричности :)
В оракле есть rowid - внутренний адрес записи, его нельзя использовать как ключ для связок, т.к. он может неявно сменится. Однако его можно использовать при идентификации записи на лету, например, чтобы проапдейтить запись, выбранную курсором. Кстати, в MS SQL тоже есть нечто подобное, только инфу из этого поля не посмотреть (впрочем она и в оракле как таковая интереса особого не представляет :) ), а для аналогичных манипуляций используется CURRENT OF.

> Но даже для курсора не гарантируется стабильность

Не, если базу не колбасить на ходу, то у записи он сам по себе не меняется. Более того, в пакетах оракла частенько записи адресуются по rowid. Не будут же разработчики сами себе мину закладывать :)

> [13] Anatoly Podgoretsky © (16.11.06 10:20)
> Он так не говорил, он не так говорил, сравни
Сравниваю и все равно не понимаю.

> [2] MikePetrichenko © (15.11.06 23:49)
> > У строк в БД не бывает номеров.
> Ошибочка. Oracel имеет внутренний идентификатор (уникальный) для каждой строки таблицы.

> [4] MikePetrichenko © (16.11.06 00:04)
> > У строк в БД не бывает номеров.
> P.S. Сам Oracle рекомендует использовать (и широко использует сам) этот внутренний идентификатор (GUID кстати).

> Говорил он про ROWID

> [8] MikePetrichenko © (16.11.06 01:11)
> > Прочитал. Ты, видимо, имел в виду ROWID
> Ошибочка вышла. ROWID актуален для готового запроса (курсора). Чтим внимательнее.

Все таки нитересно, что скажет сам MikePetrichenko

> ANB (16.11.2006 10:25:14) [14]

Почему не посмотреть, обычное целочисленое поле, тип timestamp, сейчас рекомендуют использовать название row_version - стабильно до изменения поля. Значение только нарастает, удобно для идентификации в курсоре, особенно для целей репликации. Как бы это можно было делать, если бы это нельзя было прочитать. Поле не автоматическое, создавать надо ручками в таблице.

> ANB (16.11.2006 10:26:15) [15]

Они мину не закладывают, они используют по назначению, а вот пользователи не всегда, не понимая сущности данного поля

> Sergey13 (16.11.2006 10:29:16) [16]

> Сравниваю и все равно не понимаю.

Ну тогда не могу помочь, объяснять правила русского языка, особенно по части предлога НЕ у меня всегда плохо получалось, поэтому стараюсь писать простые утверждения, вместо отрицания.

← →
Percent (2006-11-16 11:34) [20]

О, как дискуссия разгорелась...

Значит так: теория реляционных баз данных исключает понятие "номер строки" как таковой.

Правило Кодда №2 (правило гарантированного доступа) гласит: "Любая и каждая величина (элементарное значение) в реляционной БД должна быть гарантированно логически доступна, обращаясь к названию таблицы, значению первичного ключа и имени столбца".

Все. Никаких номеров строк.

Введение понятия номеров строк отдельными производителями отдельных СУБД на теорию РБД не влияет. Я понимаю, что у них (производителей) для своих собственных нужд и значение синуса может достигать четырех, но: теория первична, производители идут лесом.

Вот если автор вопроса введет в конкретной таблице конкретной БД в частном порядке поле [Номер строки], и назначит его первичным ключом, и ему надо будет получить значение какого-либо поля из этой таблицы, идентифицируемое неким значением [Номера строки], тогда можно сформулировать вопрос так, как сформулировал его автор. Но это будет уже подмена понятий - "первичного ключа" на "название поля, используемого в качестве первичного ключа". Не более того. А первичный ключ, как был первичным ключом, так им и останется.

Значение Найти похожие ветки