Hi forumers,

I'm trying to use kexi on a Debian buster using PostgreSQL V.12 from the official rep (https://apt.postgresql.org/pub/repos/apt/ buster-pgdg main), but each time I try to import a DB, it fails with the "I18N_ARGUMENT_MISSING" error - whether I try to import "Structure and data" or "Structure only".

Is it a know problem with PG V.12 or is it another thing, such as language file(s) missing or because of my locale setup that is a bit unusual ? :

Code: Select all

LANG=fr_FR.utf8
LANGUAGE=
LC_CTYPE="fr_FR.utf8"
LC_NUMERIC=en_US.utf8
LC_TIME="fr_FR.utf8"
LC_COLLATE="fr_FR.utf8"
LC_MONETARY="fr_FR.utf8"
LC_MESSAGES=en_US.utf8
LC_PAPER="fr_FR.utf8"
LC_NAME="fr_FR.utf8"
LC_ADDRESS="fr_FR.utf8"
LC_TELEPHONE="fr_FR.utf8"
LC_MEASUREMENT="fr_FR.utf8"
LC_IDENTIFICATION="fr_FR.utf8"
LC_ALL=


Listing of intalled pkgs :

Code: Select all

ii  kexi                   1:3.1.0-4    amd64        visual database applications builder
ii  kexi-data              1:3.1.0-4    all          data files for kexi
ii  kexi-postgresql-driver 1:3.1.0-4    amd64        PostgreSQL support for kexi
ii  kexi-web-form-widget   1:3.1.0-4    amd64        web form widget for Kexi
--------------------------------
ii  postgresql                      12+213.pgdg100+1              all          object-relational SQL database (supported version)
ii  postgresql-12                   12.2-2.pgdg100+1              amd64        object-relational SQL database, version 12 server
ii  postgresql-12-asn1oid           1.2-3.pgdg100+1               amd64        ASN.1 OID data type for PostgreSQL
ii  postgresql-12-debversion        1.1.1-3.pgdg100+1             amd64        Debian version number type for PostgreSQL
ii  postgresql-12-dirtyread         2.2-1.pgdg100+1               amd64        Read dead but unvacuumed tuples from a PostgreSQL relati
ii  postgresql-12-first-last-agg    0.1.4-4-gd63ea3b-2.pgdg100+1  amd64        PostgreSQL extension providing first and last aggregate
ii  postgresql-12-hypopg            1.1.3-1.pgdg100+1             amd64        PostgreSQL extension adding support for hypothetical ind
ii  postgresql-12-ip4r              2.4.1-2.pgdg100+1             amd64        IPv4 and IPv6 types for PostgreSQL 12
ii  postgresql-12-partman           4.3.0-1.pgdg100+1             amd64        PostgreSQL Partition Manager
ii  postgresql-12-periods           1.1-1.pgdg100+1               amd64        PERIODs and SYSTEM VERSIONING for PostgreSQL
ii  postgresql-12-pg-qualstats      1.0.9-1.pgdg100+1             amd64        PostgreSQL extension to gather statistics about predicat
ii  postgresql-12-pg-stat-kcache    2.1.1-3.pgdg100+1             amd64        PostgreSQL extension to gather per-query kernel statisti
ii  postgresql-12-pgaudit           1.4.0-2.pgdg100+1             amd64        PostgreSQL Audit Extension
ii  postgresql-12-pgmemcache        2.3.0-7.pgdg100+1             amd64        PostgreSQL interface to memcached
ii  postgresql-12-pgmp              1.0.4-2.pgdg100+1             amd64        arbitrary precision integers and rationals for PostgreSQ
ii  postgresql-12-pgpool2           4.1.1-2.pgdg100+1             amd64        connection pool server and replication proxy for Postgre
ii  postgresql-12-pgrouting         3.0.0~rc1-1.pgdg100+1         amd64        Routing functionality support for PostgreSQL/PostGIS
ii  postgresql-12-pgrouting-doc     3.0.0~rc1-1.pgdg100+1         all          Routing functionality support for PostgreSQL/PostGIS (Do
ii  postgresql-12-pgrouting-scripts 3.0.0~rc1-1.pgdg100+1         all          Routing functionality support for PostgreSQL/PostGIS - S
ii  postgresql-12-pgtap             1.1.0-2.pgdg100+1             all          Unit testing framework extension for PostgreSQL 12
ii  postgresql-12-pldebugger        1:1.0-10-g2a298eb-2.pgdg100+1 amd64        PostgreSQL pl/pgsql Debugger API
ii  postgresql-12-postgis-3         3.0.1+dfsg-2.pgdg100+1        amd64        Geographic objects support for PostgreSQL 12
ii  postgresql-12-postgis-3-scripts 3.0.1+dfsg-2.pgdg100+1        all          Geographic objects support for PostgreSQL 12 -- SQL scri
ii  postgresql-12-powa              3.2.0-2.pgdg100+1             amd64        PostgreSQL Workload Analyzer -- PostgreSQL 12 extension
ii  postgresql-12-prefix            1.2.9-2.pgdg100+1             amd64        Prefix Range module for PostgreSQL
ii  postgresql-12-preprepare        0.9-3.pgdg100+1               amd64        pre prepare your PostgreSQL statements server side


Hello,
Is there any other message? The I18N_ARGUMENT_MISSING is a possible mistake on KEXI side but it's only about a message. If you get an import error it's good to nail down the cause e.g. by creating a new database first on the same server.

Possible relation is here viewtopic.php?f=221&t=108331 on this forum.

jstaniek wrote:Hello,
Is there any other message? The I18N_ARGUMENT_MISSING is a possible mistake on KEXI side but it's only about a message. If you get an import error it's good to nail down the cause e.g. by creating a new database first on the same server.

Possible relation is here viewtopic.php?f=221&t=108331 on this forum.

Hi jstaniek,

Yup there's other text when trying to import my DB :

Code: Select all

Import failed.
Could not import from database "mydb" (connection "suadmin@localhost"). Error reading table "account".
(I18N_ARGUMENT_MISSING)
(I18N_ARGUMENT_MISSING)
You can click back button and try again.


In this DB :
* all types and domains are defined into schema "public"
* all tables and views are stored into different schemas (none into the "public" one)
* several tables use the same name into different schemas.

Jean-Yves

Hmm, there's also an output from the command line :

Code: Select all

$ kexi-3.1
gui updated 3 min. ago, next auto-update in 57 min.
"0 instead of 1 arguments to message {<para>%1</para><para...} supplied before conversion."
NOTICE:  extension "fuzzystrmatch" already exists, skipping
"/home/niff/"
"/home/niff/"
File Destination...
Current file name: "/home/niff/mydb.kexi"
Structure and data selected
File Destination...
Current file name: "/home/niff/mydb.kexi"
Structure and data selected
"/home/niff/mydb.kexi"
Performing import...
CONNECTING...
NOTICE:  extension "fuzzystrmatch" already exists, skipping
GETTING TABLENAMES...
Reading list of tables...
"<qt><p><html>Could not import project from database “mydb” (connection “suadmin@localhost”). Error reading table “account”.</html></p>"
 ""
"0 instead of 2 arguments to message {<para>Import failed....} supplied before conversion."
":ProjectMigrationDestinationDir"
QUrl("")


Jean-Yves

One quick idea. Does "SELECT * from account" work for the suadmin@localhost? If not, KEXI needs to know there's some prefix/name space needed. Since there's no way to do that in KEXI importer, you would need to reconfigure the db to make "SELECT * from account" at least temporarily work.

KEXI importer uses the SELECT query to discover columns of the table (well it uses "SELECT * FROM ... LIMIT 0" to be strict).

PS: In the future KEXI would be able to connect to existing databases without any importing, that's a wish https://bugs.kde.org/show_bug.cgi?id=380088 worth voting for.

One quick idea. Does "SELECT * from account" work for the suadmin@localhost? If not, KEXI needs to know there's some prefix/name space needed. Since there's no way to do that in KEXI importer, you would need to reconfigure the db to make "SELECT * from account" at least temporarily work.

* No it can't, as all tables and views are into different schemas - in fact the "public" schema only contains types, domains, functions and procedures definitions,
* however : "SELECT * FROM accounting.account" works,
* I can't modify my db to make : "SELECT * from account" work, as it would involve a very dangerous malpractice : put those tables into the "public" schema, moreover, I can't even do that as I have tables with the same name in different schemas (eg: accounting.account, employee.account, common.account, etc),
* Note that after altering the : "search_path" variable for user "suadmin@localhost", the failure was upon another table (address), which seems logical.

As I selected "import with structure", it seems logical to me that Kexi first retrieves types, domains, schemas structures, tables and view names, the whole shebang and finally, tables and views from schemas with a FQDN, meaning : SCHEMA_NAME.TABLE_NAME (?)

OK, thanks.

I'd like to remind that importing the database will create a new db, be it kexi file or one the pgsql server, possibly the same as the source one. Then, the destination db won't take advantage of your securing approach through the schemas. That's unsupported by current KEXI, though it would be attractive feature.

So based on that, would you be able to put those tables into the "public" schema e.g. for specific user temporarily? It does make it insecure given what I said above.

Cheers.

Hmm, you read me too fast, I can't because many tables have the same name but a different schema.

> many tables have the same name but a different schema.

I got it, It's still possible to "put" them in the "public" schema, e.g. by dumping the SQL, doing some table names modification and importing back to a new db. This is extra work the KEXI migrator would do for us on the fly. But probably implementing https://bugs.kde.org/show_bug.cgi?id=380088 has more value.

No, I don't have time for that.
About bug #380088, I don't see the advantage to be able to open a DB engine without any processing behind.
I'll fall back to a commercial software because I really need to import/export out of the box without any hassle.
Anyway, thanks for your time.