Select RowNum no FB
Existe uma função no Oracle que retorna exatamente o número da linha do registro, ex:
tabela clientes
id nome
---------------------
2 Carlos
5 Marcos
6 Maria
8 Fulano
10 Joao
select nome, ROWNUM(nome) from clientes
Resultado: JOAO 5
Existe algo assim no FB? Onde no meu select ele me retorna o número da linha do registro?
tabela clientes
id nome
---------------------
2 Carlos
5 Marcos
6 Maria
8 Fulano
10 Joao
select nome, ROWNUM(nome) from clientes
Resultado: JOAO 5
Existe algo assim no FB? Onde no meu select ele me retorna o número da linha do registro?
Rodolpho123
Curtidas 0
Respostas
Gandalf.nho
12/01/2005
Pelo que sei, esse recurso não existe no IB/FB
GOSTEI 0
Afarias
12/01/2005
rdb$db_key
select rdb$db_key, etc from tabela;
T+
select rdb$db_key, etc from tabela;
T+
GOSTEI 0
Vinicius2k
12/01/2005
Anderson,
Nunca precisei utilizar este recurso, mas nunca consegui entender o que exatamente está armazenado nesta ´coluna de sistema´. Vc poderia me esclarecer ?
Quando faço este select o valor retornado é algo como um caracter especial tipo ´|´, dependendo da ferramenta GUI, mas já no ISQL parece um hash, ou algo do tipo (uma notação HEXA).
T+
Nunca precisei utilizar este recurso, mas nunca consegui entender o que exatamente está armazenado nesta ´coluna de sistema´. Vc poderia me esclarecer ?
Quando faço este select o valor retornado é algo como um caracter especial tipo ´|´, dependendo da ferramenta GUI, mas já no ISQL parece um hash, ou algo do tipo (uma notação HEXA).
T+
GOSTEI 0
Afarias
12/01/2005
RDB$DB_KEY contém o ´endereço´ do registro... não no disco, mas ´internamente´ para o banco de dados.
Este campo é um SMALLINT e guarda 8 bytes (para tabelas) -- a forma como vc o vê é pq por padrão o interbase mostra esse campo num formato hexadecimal (como vc pode notar)
Bom esse valor não se mantem igual depois de um backup/restore -- não é algo FIXO.
E, mesmo após encerrar uma transação pode mudar -- após um COMMIT (hard commit apenas) -- pode haver o ´garbage collection´ que tornaria a posição (endereço) livre para um outro registro (registros excluídos)
Existem alguns ´usos´ para este campo, como sugerido por [b:b5db53f2dc]Claudio Valderrama[/b:b5db53f2dc] em seus artigos (ótimo site: http://www.cvalde.net/) :
1- A db_key é mais veloz que uma chave primária (visto q trata-se do endereço do registro - a chave tem ainda q ser convertida nesse endereço)
2- Algumas tabelas não tem chave primária e fica difícil excluir um registro duplicado (todos os campos iguais)
entre outros...
Sugiro como leitura:
http://www.cvalde.net/document/mysteriousDbKey.htm
http://www.cvalde.net/document/practical_use_of_the_rdb.htm
existe uma tradução do 2º artigo por [b:b5db53f2dc]Carlos H. Cantu[/b:b5db53f2dc] tb:
http://www.firebase.com.br/cgi-bin/firebase.cgi/artigo?ID=262
Espero q ajude.
T+
Este campo é um SMALLINT e guarda 8 bytes (para tabelas) -- a forma como vc o vê é pq por padrão o interbase mostra esse campo num formato hexadecimal (como vc pode notar)
Bom esse valor não se mantem igual depois de um backup/restore -- não é algo FIXO.
E, mesmo após encerrar uma transação pode mudar -- após um COMMIT (hard commit apenas) -- pode haver o ´garbage collection´ que tornaria a posição (endereço) livre para um outro registro (registros excluídos)
Existem alguns ´usos´ para este campo, como sugerido por [b:b5db53f2dc]Claudio Valderrama[/b:b5db53f2dc] em seus artigos (ótimo site: http://www.cvalde.net/) :
1- A db_key é mais veloz que uma chave primária (visto q trata-se do endereço do registro - a chave tem ainda q ser convertida nesse endereço)
2- Algumas tabelas não tem chave primária e fica difícil excluir um registro duplicado (todos os campos iguais)
entre outros...
Sugiro como leitura:
http://www.cvalde.net/document/mysteriousDbKey.htm
http://www.cvalde.net/document/practical_use_of_the_rdb.htm
existe uma tradução do 2º artigo por [b:b5db53f2dc]Carlos H. Cantu[/b:b5db53f2dc] tb:
http://www.firebase.com.br/cgi-bin/firebase.cgi/artigo?ID=262
Espero q ajude.
T+
GOSTEI 0
Vinicius2k
12/01/2005
Obrigado Anderson ! :wink:
Eu, realmente, não fazia idéia do que exatamente era e de como usar a db_key.
Vc ajudou muito !
T+
Eu, realmente, não fazia idéia do que exatamente era e de como usar a db_key.
Vc ajudou muito !
T+
GOSTEI 0
Tiagorocha
12/01/2005
Estou tendo problemas ao utilizar o RDB$DB_KEY para referenciar registros dentro de uma procedure...
Minha intenção é criar uma chave primária em uma tabela que ainda não possui para resolver alguns problemas que ocorrem quando tento editar registros. Para isso criei um campo inteiro simples (CODDEPEND), um generator (CODDEPEND) e uma procedure (ATRIBUICOD) para tentar numerar esses registros antes de aplicar as restrições de chave primária ao campo.
A procedure compila sem nenhum problema, mas quando tento executá-la recebo a seguinte mensagem de erro (um erro de conversão entre variáveis, um ´type mismatch´) :
Onde é que estou errando?
Minha intenção é criar uma chave primária em uma tabela que ainda não possui para resolver alguns problemas que ocorrem quando tento editar registros. Para isso criei um campo inteiro simples (CODDEPEND), um generator (CODDEPEND) e uma procedure (ATRIBUICOD) para tentar numerar esses registros antes de aplicar as restrições de chave primária ao campo.
A procedure compila sem nenhum problema, mas quando tento executá-la recebo a seguinte mensagem de erro (um erro de conversão entre variáveis, um ´type mismatch´) :
Overflow occurred during data type conversion. conversion error from string "„".
Onde é que estou errando?
CREATE PROCEDURE ATRIBUICOD
AS
DECLARE VARIABLE CHAVEBD INTEGER;
BEGIN
FOR SELECT RDB$DB_KEY FROM DEPENDENTES
INTO :CHAVEBD DO
UPDATE DEPENDENTES SET CODDEPEND=GEN_ID(CODDEPEND,1)
WHERE RDB$DB_KEY=:CHAVEBD;
SUSPEND;
ENDGOSTEI 0
Vicente Santos
12/01/2005
isso funcionaria caso tivesse chave primaria
GOSTEI 0