- Original Message -
From: Fiasco [EMAIL PROTECTED]
To: Paul DuBois [EMAIL PROTECTED]
Sent: Saturday, April 20, 2002 7:28 PM
Subject: Re: Re: problem with load data local infile
The error I receive is:
Can't stat file 'filename' (errcode 2)
It can't stat *filename*? Don't make up error messages, report them
exactly.
Can't get stat of 'filename' (Errcode 2)
Filename being the fully qualified path of whatever file I am trying to
infile.
I tried local infiling the following two files
/usr/bin/znew (exists on both machines)
/usr/games/worms (exists only on client machine)
What are the modes on both files?
Both files are world readable.
Even though I specified local on the infile
statement, mysql successfully imported
/usr/bin/znew into the specified table.
/usr/games/worms was returned the same
can't stat file (errcode 2) message.
Then its mode is probably different. Perhaps execute-only.
Modes are the same.
It looks like the LOCAL argument is being
ignored all together.
Mmm ... doubt it.
Why is the load data local infile statement successfully importing files
that reside
on the mysql host but not the mysql client machine? With local specified,
the host
shouldn't even be looking for files located on it should it?
Is it posible that my host is 3.23.23-beta, and
that my client is a newer version of mysql and
that the client has local disabled? Whats the
quickest way to find the version of my client? I only
have access to mysql through perl/php
Invoke the mysql_get_client_info() function. It'll tell you
the version of the client library.
I only have access to the database via perl or php. How do I call
the C API function mysql_get_client_info() from perl?
It's entirely possible, likely even, that the client library has been
updated. But based on your /usr/bin/znew, /usr/bin/games experience,
that seems unlikely.
Is there a way to find out what startup options
were specified for Mysql through perl dbi or
php access?
Not that I know of.
- Original Message -
From: Paul DuBois [EMAIL PROTECTED]
To: Darren Vollmer [EMAIL PROTECTED]; [EMAIL PROTECTED];
Victoria
Reznichenko [EMAIL PROTECTED]
Sent: Saturday, April 20, 2002 5:12 PM
Subject: Re: Re: problem with load data local infile
At 6:34 -0500 4/20/02, Darren Vollmer wrote:
The file is in a world readable directory tree.
Shouldn't the LOCAL qualifier make mysql read the file from the
client
running and not the host?
I tried to LOAD DATA LOCAL INFILE on using the name (and no path)
of
a
mysql
FRM file that is in the databases directory on the Mysql host. The
server
found the file even though I specified local. Don't know if that
means
anything or not, or if that is normal mysql behavior.
exp;
load data local infile 'table.frm' replace into table testtable
Shouldn't mysql be looking for table.frm on my client machine and
not
the
server?
LOCAL requires only that you be able to read the file.
With the LOCAL keyword, the program on the client machine reads the
file
and sends it to the server to be inserted into the table. The MySQL
server
takes those records, and it's what accesses the table.frm file.
How could the client access table.frm? That file isn't even on the
client
host necessarily.
Something that might account for the difficulty, if you've upgraded
MySQL
recently:
A change was made in MySQL 3.23.49 that causes LOCAL to be disabled
(by
default?). You may be able to re-enable it by invoking mysql with
the
--local-infile option. Try mysql --help to see if that option is
listed
in the help message.
By the way, what was the error message you got?
- Original Message -
From: Victoria Reznichenko [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, April 20, 2002 6:14 AM
Subject: Re: Re: problem with load data local infile
Darren,
Saturday, April 20, 2002, 1:23:54 PM, you wrote:
DV The file does exist. The file and its directory are 0777
permission.
Such permissions are setting on all dirs, that contain path to
your
dir?
Don't forget that you should have permissions to go through dirs
...
DV Darren
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail
[EMAIL PROTECTED]
Trouble unsubscribing? Try:
http://lists.mysql.com/php/unsubscribe.php
-
Before posting, please check:
