Firebird Unidirecional?

Colega,

O IB/FB não, aliás acho que nenhum SGBD é unidirecional... não no sentido que vc colocou, não sei se existiria uma outra interpretação para este termo que pudesse justificar essa colocação.

O que vc *deve* ter visto é falar-se do dbExpress, que sim, é unidirecional, não só para o IB/FB mas para todos os SGBDs que ele é capaz de interagir... Mais precisamente, TSQLDataSet e TSQLQuery, já que a grande maioria das situações usa-se a Midas (Provider + ClientDataSet) para ´driblar´ essa limitação de direção do DBX.

T+

|tenho feito testes e retrocedido minhas consultas SQL em Firebird,
|porque?

como tem feito isso?? usando C com Embedded SQL?? ou dentro de StoredProcs (for select)??

Ou a partir de uma aplicação comum? O ´cursor´ q vc está navegando é do buffer local do componente q está usando, e não do IB ou FB -- que realmente só possuem cursores uni-direcionais.


|O IB/FB não, aliás acho que nenhum SGBD é unidirecional...

o IB e FB são Vina... aliais, a maior parte dos SGBD não suportam cursores bi-direcionais -- até onde sei (AFAIK).


T+

Então todo cursor biderecional é resultado de buffer no DataSet ?
Se for, honestamente, não sabia... peço ao colega que me desculpe... :oops:

T+

Isso é uma ´confusão´ muito comum...

Até pq, visto q sempre trabalhamos nas ´camadas mais superiores´ não estamos tão interessados nos detalhes mais ´internos´ do banco

Até mesmo o próprio manual do desenvolvedor do IB 6.0 dá a entender que tais cursores bi-direcionais existem (no IB e não nos componentes).


T+

Legal ! Aprendi mais uma ! :D

Se analisar apenas este aspecto, a grosso modo podemos dizer que a única diferença entre o DBX e o IBX, por exemplo, é que o DBX não tem buffer próprio, precisando de uma ´ajudinha´ da Midas, não é verdade?

blz, esclareci minha dúvida quanto este tópico, só mais uma, a respeito desse buffer, ele serve para que as tranzações aconteçam somente no commit ou este ato é feito pelo próprio SGDB, ou seja ele quem aguarda o commit para concluir a alteração (ões) ou o buffer que espera uma chamada assim para descaregar no SGDB? a exemplo do paradox que tbm usa um buffer temporário...

mais uma dúvida o fato de quase nenhum SGDB suportar cursores bi-direcionais se dá pelo fato de os índices não serem seqüênciais diferentemente de banco de dados locais como o paradox? me corrija se eu estiver errado mas acho que eles tem chaves lógicas?

Exato!

O DBX não implementa este buffer pois está ´baseado´ na existência dos CDS/DSP (Midas). Como o CDS é um ótimo ´Buffer´ não tinha pq implementar buffers tb nos componentes do DBX -- é como uma ´separação de tarefas´




As transações nada tem a ver com esse buffer Bruno. Ele serve apenas para permitir a ´navegação livre´ dos registros. Não tem qualquer relação com as funções do SGBD (como as transações)




Não.

Entretanto, quando se trabalha com Cached Updates ou ClientDataSets -- as alterações realizadas nos dados não são aplicadas diretamente no SGBD mas apenas no ´buffer´ local.

Tais atualizações são aplicadas ao SGBD apenas quando da chamada do ApplyUpdates -- este é um mecanismo local -- que é independente e ainda necessita do controle de transações do banco (commit/rollback)




Não acredito. Acho q isso ocorre apenas por uma questão de racionalidade -- cursores bi-direcionais tem ´alto´ custo de utilização (recursos do sistema) fora implementação e suporte do SGBD, e geralmente são pouco necessários nas implementações de sistemas C/S -- sendo assim, é uma funcionalidade ´deixada de lado´




Desculpe, não entendi.


T+