Logos300,

А ты созидай таблицу соотв. запросом при помощи TIBQuery, а открывать/работать с ней потом уже сможешь при помощи TIBTable или TIBDataset.

Любезный,

Или в пользу TIBDataset. И не надо здесь нам штампов, в ряде ситуаций TIBTable вполне себе функциональный и удобный объект.

kdv,

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

ЛюбезныйНах-нах. Двунаправленный курсор на больших объемах данных - это большая проблема, тем более учитывая, что компонент хватает все поля из таблицы.

Я не зря сделал ремарку про определенные ситуации (надо просто голову подключать), в которых использование IBTable является не только обоснованным, но и достаточно удобным. Например, по собственному опыту, для редактирования разумных по размеру справочников из десятков (и даже сотен) тысяч позиций, на объемах которых никаких видимых деградаций не возникает. Что касается "хватает все поля", то тут становится совершенно очевидным, что вы с ним реально не работали, ну или по крайней мере в исходники не заглядовали. Потому и оценочные суждения такие. А ведь могут признать за чистую монету.
Ты в самом деле считаешь, что использование в IB/FB компонента с единственной транзакцией на чтение и запись - это адекватно?
И не только считаю, но и вовсю в таком виде их использую еще с доФИБОвских дремучих времен. Надо просто уметь грамотно их готовить. ))

YuRock,

Ну уж нет, - хардкодить, так хардкодить. И, кстати, сам по себе IBTable и иже с ним тоже не визуальный компонент, ежели чо. ))

Погодите вы ругаться, мы еще таблицу не создали. Через createTable. ))

Док,

Вот вы второй уже ролик (без мыла) сюда суете, которые на первом айпаде, к примеру, не кажутся. Быть может, на пальцах тогда лучше что-то изобразить? А то смотрится все это в стиле пропала мысль. В то время как все мы с нетерпением ждем итогов применения TIBTable.CreateTable. )))