Menu

#1070 SQL created in graph editor don't include schema name

3.9.0
open
nobody
None
5
2018-12-22
2013-01-18
Nick
No

If I select a table and I create the standard SELECT command with the option (right click -> Script -> Create SELECT for the table) I obtain the correct command like this:

SELECT numero_dossier,operatore_cm,data_di_nascita,anno_di_nascita FROM "decs_casenet"."casenetdata";

If I add the table to the graph editor with the option (right click -> add to the graph) and I select some columns to create the command, I obtain the SQL code without the schema name like this:

SELECT
casenetdata.numero_dossier,
casenetdata.operatore_cm,
casenetdata.data_di_nascita,
casenetdata.anno_di_nascita
FROM casenetdata

If I try to execute the command in the Result, I receive an error because the table "casenetdata" doesn't exist. How can I force Squirrel to add the schema name also in the graph editor?

Discussion

  • Nick

    Nick - 2013-01-18

    I attach the "Dump Application" log here if this can help.

     
  • Nick

    Nick - 2013-01-22

    I forgot to mention that I use PostrgeSQL 9.2.

     
  • Nick

    Nick - 2013-02-19

    Hi,

    I have found that the problem is that the graph editor uses always the default schema name "public".
    If I try to build a query with the tables from a different schema, for instance "schematest", the graph editor returns an error because he looks for the tables in the "public" schema and not in the "schematest". So I have for example my table here: "schematest"."table1", and the graph editor assumes this: "public"."table1".

     
  • paulinik

    paulinik - 2013-03-06

    That's also an issue when using an Oracle DB. To execute the resulting SQL, you always have to copy and paste it to a worksheet with the wanted schema set. Very cumbersome.

     
  • Nick

    Nick - 2013-05-06

    Hi,

    this issue is still present in the last snapshot.
    Perhaps I have to open a ticket unser "snapshot" too?

     
  • microdisney

    microdisney - 2014-02-16

    Having same issue with SQL Server.. the FQN really needs to be addressed.

     

Log in to post a comment.