Start a new topic

Importing into a database using dots in the name doesn't work.

Some of my databases use a naming scheme following the Java package convention, so that I get something like the following:


> de.am_soft.sm_mtg.backend.bug_2628


I tried to import data using the import dialog of one of the tables within that database and that resulted in the following exception:


[ Row: 2, File lines: 2-124 ] FEHLER: aktuelle Transaktion wurde abgebrochen, Befehle werden bis zum Ende der Transaktion ignoriert FEHLER: falscher qualifizierter Name (zu viele Namensteile): de.am_soft.sm_mtg.backend.bug_2628.public.bcd_history
  Position: 16

That means something like a wrong name because of too many name parts. The reason most likely is that the name of the database is not quoted to support dots in its name. This is especially a problem because with only one open connection the name of the database wouldn't be necessary most likely, but can't be changed at all like can be seen in the attached screenshots.


Would be great if you could have a look and improve this. Thanks!


Hej


I very much wonder a database should accept the dot as a part of an object name at all. It is used as delimiter between the names of different "objects" if you want/need to give a more fully qualified name, e.g.:


  • Schema: SCHEMA#1, SCHEMA#2
  • Table: TABLE_AS_EXAPMLE
  • Attribute: NEW_ATTRIBUTE$WITHOUT_A_PURPOSE


  • FQN for the table: SCHEMA#1.TABLE_AS_EXAPMLE
  • FQN for the attribute: SCHEMA#1.TABLE_AS_EXAPMLE.NEW_ATTRIBUTE$WITHOUT_A_PURPOSE

-- I usually do not write like this as using aliases make code much more
-- readable for me, this is solely for illustrative purposes.
          select SCHEMA#1.TABLE_AS_EXAPMLE.NEW_ATTRIBUTE$WITHOUT_A_PURPOSE
           from SCHEMA#1.TABLE_AS_EXAPMLE
left outer join SCHEMA#2.TABLE_AS_EXAPMLE
             on SCHEMA#1.TABLE_AS_EXAPMLE.NEW_ATTRIBUTE$WITHOUT_A_PURPOSE =
                  SCHEMA#2.TABLE_AS_EXAPMLE.NEW_ATTRIBUTE$WITHOUT_A_PURPOSE
          where SCHEMA#2.TABLE_AS_EXAPMLE.NEW_ATTRIBUTE$WITHOUT_A_PURPOSE is null;

But then, I might have got wrong the issue all together.

 

Cheers


Thiemo

It seems the problem only happens when emptying the table using either TRUNCATE or DELETE is chosen. When testing the import with an initially empty table, that worked instantly.

Hi Thorsten,


Converting this to a ticket.  Will ask you for some more information in context of the ticket. 


Regards 


Ulf

Login or Signup to post a comment