Sub-query nao funciona no Interbase??

Já tentou usar VIEWs?

Sim, com views naturalmente funciona...

Só que eu não queria ´poluir´ o banco com dezenas de views, visto que faço amplo uso sub-queryes em diversos lugares, tanto dentro de storeds como em TQuerys usadas para relatórios no Delphi.

Mas parece que não há outra solução mesmo...

Não tem mesmo!

Mas nos casos das UNION não tem nada q ver com isso e no IB/FB funciona perfeitamente.


T+

Melhor mudar de banco se puder. Pô, até Access q não é SGDB aceita isso! (Não q eu o recomende pra aplicações Cliente/Servidor).

Criar muitas Views realmente deixa o banco poluído..., além de stored procedures, etc. O melhor é o banco de dados só cuidar dos dados e a parte funcional ser sempre via aplicação servidora. Imagina manter views/stored procedures repetidas pra cada banco diferente q a aplicação for usar..., se não usa vários agora, pode ser q mais tarde sim, ou então mudança pra outro banco. Prender a aplicação em um banco só é pedir retrabalho futuro.

Ah.. tinha esquecido, uma ótima opção é o PostgreSQL, a versão comercial pra Windows é quase o mesmo preço do Interbase, e melhor, esse preço sem limitação de acessos ao banco, onde o Interbase sai bem mais caro neste caso.

Claro, se houver possibilidade de troca de banco no seu caso... Não é conversa de vendedor, só estou querendo expor que existe opção melhor no mercado do que o Interbase, e respeitando o custo.

A maioria dos programadores Delphi se levam pro mundo Interbase/Fb pelo fato de ter sido um produto q cresceu em uso por ser parte integrante do Delphi, e as vezes deixam de ver SGDBs melhores.. Não que Ib seja ruim, por si só é ótimo, mas cada caso é um caso.., pra aplicações multibanco ele é um dos q já me deram mais trabalho pra tratar ´ifs´.

Infelizmente o IB é compulsório, foi imposição do cliente. O jeito é meter a mão na massa e entupir o banco de views mesmo, não há solução.

Só fiquei muito surpreso de um banco como o IB não aceitar sub-query, é o primeiro banco que vejo (além do MySql) com essa limitação. (E olha que não estou falando de sub-querys na cláusula WHERE, essas quase não uso pois quase sempre dá para substituir por JOINs, muito mais eficientes)

Outra coisa que estranhei é a impossibilidade de usar na mesma query dados de dois databases diferentes. Vou ter que reunir as tabelas de todos os sistemas e jogar tudo em um imenso banco único. Por si só, isso não é problema algum, apenas acho desorganizado jogar as tabelas de sistemas diferentes em um único banco.

Sobre nao poder acessar vários bancos numa mesma query, tb é decepcionante isso. Mas tb dá pra fazer via programa, pra nao ter q fazer essa ´desorganizacao´ no SGDB.

Mas ao mesmo tempo seria deixar o banco organizado e o programa ´desorganizado´:

DataSet1.Connection := ConnectionBanco1;
DataSet1.Open;

DataSet2.Connection := ConnectionBanco2;
DataSet2.Open;

//tendo a necessidade, manipular relacao entre os dois via while not Eof...

: / é feio tb, mas é só pra expor essa possibilidade...

[quote:a8d91d0bd3=´Bon Jovi´]Sobre nao poder acessar vários bancos numa mesma query, tb é decepcionante isso. Mas tb dá pra fazer via programa, pra nao ter q fazer essa ´desorganizacao´ no SGDB.
Mas ao mesmo tempo seria deixar o banco organizado e o programa ´desorganizado´:
DataSet1.Connection := ConnectionBanco1;
DataSet1.Open;
DataSet2.Connection := ConnectionBanco2;
DataSet2.Open;
[/quote:a8d91d0bd3]

É uma possibilidade, mas como você mesmo salientou, geraria uma bagunça danada no código, não vale a pena.

Aproveitando , o que posso fazer com a instrução SET DATABASE? Não consegui fazê-la funcionar e confessa que nem mesmo entendi direito sua real função.

Nao conheço SET DATABASE. O que gostaria nesse caso? Ou é ainda o lance de acessar duas bases numa query?

[quote:ef68f6d6a1=´Bon Jovi´]Melhor mudar de banco se puder. Pô, até Access q não é SGDB aceita isso! (Não q eu o recomende pra aplicações Cliente/Servidor). [/quote:ef68f6d6a1]

Interessante este conselho... :lol:


[quote:ef68f6d6a1=´Bon Jovi´]Criar muitas Views realmente deixa o banco poluído..., além de stored procedures, etc.[/quote:ef68f6d6a1]

Engraçado q VIEWs e STORED PROCs jão justamente o grande lance de SGBD-Rs


[quote:ef68f6d6a1=´Bon Jovi´]O melhor é o banco de dados só cuidar dos dados e a parte funcional ser sempre via aplicação servidora. Imagina manter views/stored procedures repetidas pra cada banco diferente q a aplicação for usar..., [/quote:ef68f6d6a1]

Particularmente tenho uma opnião bem diferente.


T+

[quote:c381f598f4=´Bon Jovi´]Nao conheço SET DATABASE. O que gostaria nesse caso? Ou é ainda o lance de acessar duas bases numa query?[/quote:c381f598f4]

Exato. Não achei nenhuma documentação que realmente explicasse a utilidade deste comando, apenas se limitam a sintaxe.

Sim, mas como qualquer outro recurso, não é panacéia. VIEWS e STOREDs são ótimas para representar as regras de negócio e simplificar as consultas mais comuns aos dados, mas daí a ser obrigado a criar uma nova VIEW apenas porque eu tenho um novo relatório com apenas um detalhe qualquer diferente de outro (como uma ordenação), é bem diferente.

Imagine eu ter 5 relatórios iguais e mude apenas a ordenação, preciso criar 5 VIEWS? Claro que não.

Não vejo qual a ´panacéia´ de 5 VIEWS!!!

mas, voltando ao assunto, pq vc não posta aqui a consulta q quer fazer... é possível apenas q vc não esteja sabendo usar os recursos do SELECT corretamente!

Eu, particularmente, raramente senti falta de um recurso de sub-query.


T+

Vide a primeira msg deste tópico. Note que é impossível ordenar as 3 UNION sem usar uma sub-query OU uma VIEW.

De qq forma, para mim é caso encerrado, a solução com VIEW está ok. Apenas estranhei o IB não aceitar sub-query, pois simplesmente acho mais elegante (e econômico) resolver pontualmente com sub-query no componente TQuery do que criar uma VIEW só para satisfazer uma única consulta oriunda de um único relatório.

Já disse q é possível!

Vc só não pode ordenar as diferentes querys por campos diferentes!! E, isso nào tem nada q ver com sub-querys (ao meu ver)


T+

Ah, lembrei de outro exemplo: Quero calcular a média de determinado campo e dependendo se uma linha é inferior ou superior à média retornar um ou outro valor, exemplo:

SELECT CASE (X > MEDIA)
THEN EXPRESSAOX....
ELSE EXPRESSAOY......
END
FROM (SELECT SUM(X)/ COUNT(*) AS MEDIA
FROM TABELA) AS SOMA
JOIN TABELA

(Lembrando que este exemplo está simplificado, para não perder o foco)

puts!! tu nem respondeu quanto ao outro problema e já mandou outra coisa?!!! :?

Bom, vc pode usar SUB-QUERYS como campos SIM (nesse caso, para calcular a média) mas eu particularmente não acho uma boa opção.

A única coisa q vc não pode fazer com sub-querys é um select from outro select.


T+

Já disse q é possível!
[/quote:7c62c5083a]

Como?

Exatamente como vc colocou no 1º post!!

select campo1, campo2, campo3 from tabela1
union all
select campoA, campoB, campoC from tabela2
union all
select campoI, campoII, campoII from tabela3
order by 2,1


ele vai ordenar tudo pelo segundo campo na sequencia e depois pelo primeiro (2, 1)


T+

[quote:1423337a11=´Bon Jovi´]Melhor mudar de banco se puder. Pô, até Access q não é SGDB aceita isso! (Não q eu o recomende pra aplicações Cliente/Servidor). [/quote:1423337a11]

Claro, existe SGDB melhor que Interbase, com custo até melhor, que é o caso do PostgreSQL por exemplo.

[quote:1423337a11=´Bon Jovi´]Criar muitas Views realmente deixa o banco poluído..., além de stored procedures, etc.[/quote:1423337a11]

Ok. Mas é muito melhor trabalhar em 3 camadas e implementar as regras de negócio em módulos de aplicação no lado servidor. Como eu tinha dito, com stored procedures vc vai prender a aplicação a um determinado SGDB, ou então ter uma redundância absuurda de código quando for necessário a aplicação acessar outros SGDBs, e ainda ter o trabalho de converter toda parte de lógica! Sem falar q vai de deixar de lado todo o poder de uma linguagem POO de verdade, mas isso nem é o grande problema e sim as questões de portabilidade e redundância. Não me diga que isso é bom... Pensar só no presente é arriscado.

Você está certíssimo. O que não funciona é usar ORDER BY pelo nome do campo, (mesmo que sejam idênticos em todas as queryes que compõe a UNION, e mesmo que todas referenciem a mesma tabela).

Simplesmente me esqueci de tentar usando números de campo!

Valeu!

Ué, vc me pediu para dar um exemplo.



EXATO! Não são boa opção, e a melhor saída seria fazer um JOIN com uma sub-query contendo um select from outro select, MAS...

[quote:11462fc613=´Bon Jovi´]
Claro, existe SGDB melhor que Interbase, com custo até melhor, que é o caso do PostgreSQL por exemplo.
[/quote:11462fc613]

Bom, primeiro sobre o Postgres ser melhor ou não... é opnião sua. Segundo, neste fórum (que é exclusivo para IB/FB) as pessoas estão interessadas em explorar as facetas desses bancos -- e não, diante de qualquer falta de funcionalidade ou não conhecimento do banco, partir para outra coisa qualquer.

Em qualquer banco vecê vai se deparar com ´problemas´ ... aqui estamos para resolvê-los não para trocar os problemas por outros.


[quote:11462fc613=´Bon Jovi´]
Ok. Mas é muito melhor trabalhar em 3 camadas e implementar as regras de negócio em módulos de aplicação no lado servidor. bla bla bla[/quote:11462fc613]

É... é uma boa metodologia... mas ainda (na minha particular opnião) prefiro tirar 100 do que o SGBD pode me dar.


T+

É verdade. Entretanto, estes casos são perfeitos para VIEWs... esse é o gande lance delas: informação !

Mas, no tocante ao q vc sentiu falta, o exemplo foi bem exclarecedor.



T+