I've botched a query while developing but the result was unexpected to say the least...
the wrong query is
select ANAGRAFICA_DIPENDENTI.*, dm_dbo.PROC_MANAGER.PROC_FUNCTION as proc_function from dm_dbo.ANAGRAFICA_DIPENDENTI , dm_user, dm_dbo.PROC_MANAGER where dm_dbo.ANAGRAFICA_DIPENDENTI.MATRICOLA = dm_user.description AND dm_dbo.PROC_MANAGER.MATRICOLA = dm_dbo.ANAGRAFICA_DIPENDENTI.MATRICOLA AND dm_dbo.buyer_regionale = 'N'
the correct query is
select ANAGRAFICA_DIPENDENTI.*, dm_dbo.PROC_MANAGER.PROC_FUNCTION as proc_function from dm_dbo.ANAGRAFICA_DIPENDENTI , dm_user, dm_dbo.PROC_MANAGER where dm_dbo.ANAGRAFICA_DIPENDENTI.MATRICOLA = dm_user.description AND dm_dbo.PROC_MANAGER.MATRICOLA = dm_dbo.ANAGRAFICA_DIPENDENTI.MATRICOLA AND dm_dbo.ANAGRAFICA_DIPENDENTI.buyer_regionale = 'N'
the difference is that i forgot the NAME of the registered table in the last part of this query..
The result be it via DA or via any standard application (customized webtop, customized taskspace) or via built-from-scratch custom client is literally explosive...
ALL of the docbase to whom that query is aimed simply... go down.. and not only the docbase sitting on the server where i'm actually connected.. I'm in a cluster environment and the target docbase goes down in all the cluster node...
Maybe when using dm_dbo.attribute something goes awry? I don't know how dql exactly does the translation, although I suppose he's looking for a registered resource named "buyer_regionale" and he's not finding any, let alone a basic "sql-alike" syntax failure since i'm trying to match an attribute? unless when missing that part of the query he's doing some sheningans using dm_dbo like a "resource father" and searching though all the possible resource for a resource named buyer_regionale and that make the whole thing going down...
While the issue is solved since the query was wrong, can anyone explain this sort of issue?
