A couple of minor issues first: admin and update need to be quoted, as in "admin" and "update". But I guess you did that (or used different actual names).
I can't reproduce the problem. When I use the COPY INTO the way you write (but using my own schema, obviously), the data is copied.
The error message that you quote occurs only in one place in the code, namely in the function on the client side in the MAPI library that needs to call the callback function to do the actual reading. This message is returned if no such callback function was registered.
The callback function is always registered by the mclient program, but if you have your own code that calls the MAPI functions, you need to also implement the callback (like mclient).
At the moment, client side reading is only implemented in the mclient program.
The structure of the code is as follows: The MAPI library recognizes that the server want to read data from a file (or write data to a file), and then calls a callback function to do the actual reading (writing). These callback functions must first be registered so that the library knows about them.
This was done this way so that the application can set the policy whether or not it is allowed to read/write files and under what circumstances.
This was all implemented in mclient. Look at the call to mapi_setfilecallback and at the functions (getfile and putfile) that are registered.
On 14/06/2019 03.34, Gotwisner, Dave wrote:
Our application was working quite well when using COPY INTO when inserting data into our tables as the default MonetDB user “monetdb” into the system schema (sys).
We have subsequently added users and granted table access to the various users. At this point, INSERT works successfully, but COPY INTO does not. The error message for the COPY INTO statement indicated that we needed to use “ON CLIENT” in our load. That makes no difference.
Here are the relevant commands to the system (note the user names, passwords, schema names, and tables names were modified for this example):
Program that sets up our basic database does this:
START TRANSACTION;
CREATE USER admin WITH UNENCRYPTED PASSWORD ‘***’ NAME ‘Admin User' SCHEMA sys;
CREATE SCHEMA test AUTHORIZATION admin;
ALTER USER admin SET SCHEMA test;
CREATE USER update WITH UNENCRYPTED PASSWORD ‘***’ NAME ‘Update User’ SCHEMA test;
COMMIT;
Then, the program that creates the tables does the following:
START TRANSACTION;
CREATE MERGE TABLE x (…);
GRANT ALL ON x TO “update”;
CREATE TABLE x0 (…);
GRANT ALL ON x0 TO “update”;
CREATE TABLE x1 (…);
GRANT ALL ON x1 TO “update”;
CREATE TABLE x2 (…);
GRANT ALL ON x2 TO “update”;
CREATE TABLE x3 (…);
GRANT ALL ON x3 TO “update”;
COMMIT;
And we insert (or try to) (4 threads ingest into their own table, the merge table is used to combine the result set on queries):
START TRANSACTION;
COPY 100000 OFFSET 2 RECORDS INTO x0 FROM ‘/dev/shm/MonetDB/foo.csv’ (columnlist) ON CLIENT DELIMETERS ‘,’,’\n’;
This returns an error: !/dev/shm/MonetDB/foo.csv’: cannot retrieve files.
Because of company policy, I can’t provide the schema, but the columns in the csv file and the schema differ, which is why I am using the (…) and (columnlist) in the example.
Again, when I omit the CREATE USER, CREATE SCHEMA, and GRANT clauses, everything works correctly.
Any ideas on what is needed to make it work? Right now, the ingest application and MonetDB are on the same server. In the future, that might not be true.
We are running 11.33.3 on CentOS 7.
Thanks,
Dave
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list