Hi List!
Is anobody still looking at bug #568527 (Load Infile
not working with PHP 4.2.1)? We've got there a quite
simple fix that only need to be tested under windows
OS to ensure no error is returned.
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi List,
With the parser bug system, both loic and rabus have seen the bug reports
and asked what they actually are.
So, to aid everybody in future, there is a new script with phpMyAdmin.
scripts/decode_bug.php3
Paste the bug data into it, and hit submit.
It will give you the data output.
On the note of the parser bug output.
We have had two bug reports with it,
588485 and 588116.
Both of them have been the simple problem that the uploaded file was not
ASCII, and contained invalid binary data that the system could not handle.
I'm not sure what the behavior was before the SQL parsers were used, but I
think it would have dumped the input as invalid.
I see two fixes:
1. Change the upload message to specify ASCII files are required.
OR
2. Handle binary files that are uploaded.
Doing #2 would be a major undertaking and very difficult due to the amount
of work needed. Instead I think that #1 should be implemented. Because
sending binary data to something expecting ASCII is definetly a case of
user error.
BTW, nowhere does the SQL Parser have a problem with blob data in as a
binary format, that is handled correctly by the SQL parser already.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
Hi List!
Marc wrote:
>Can I add to this:
>"A good test is to browse a table, then edit a
>row and save it. There will be an error message if
>phpMyAdmin cannot determine the correct value
>of this configuration variable."
Yep you can as it is indeed a good test.
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
In config.inc.php3, we say:
"However, we recommend that you do
test to see that the auto-detection code works in your system."
Can I add to this:
"A good test is to browse a table, then edit a row and save it. There will
be an error message if phpMyAdmin cannot determine the correct value
of this configuration variable."
Marc
hi all,
what i think should still be improved is the way to get to the
documentation... at the moment we basically assume (hope/pray whatever) that
anybody has read the document fully and still remembers it when he uses PMA.
now my suggestion would be to have a small function
call_docu($anchor)
which, depending on wether javascript can be used, will write the javascript
code to open the docu at the specified anchor, or a simple <a href> together
with some nice little ? symbol.
then we would 'just' have to go through the docu and enter lots of anchors
so we can call this function at all places throughout pma to show the user
an easy way towards the docu.
idealy a ? icon should be beside every user input field. now this would
require some more docu _and_ i really think by then we should split up the
docu into smaller parts, so that we don't need to send the whole docu file
every time, so it would be something like:
call_docu($topic,$anchor).
i expect it will take some time until this is fully realized, but i'd
suggest i'd do a function for it after 2.3.0 and start splitting the docu
and then everybody could just try to keep in mind to add some functioncall
if he stumbles across some place in the source that needs explanation, so it
will get better after time.
so:
1) do you agree to try to go in this direction
2) wasn't there some thought on having the docu in a different format?
(sgml, xml or whatever)
3) i expect nobody ever really hoped we could get the whole docu
translated, or?
--
Mike Beck
mike.beck(a)users.sourceforge.net
> > My idea was to introduce something like context help in phpMyAdmin.
> > I'd also add those ? icons to the interface, but instead of
> jumping to an
> > anchor in the documentation I'd prefer to display a short
> (maybe even
> > localized) text in a JS window that tells the user more a
> bout a specific interface
> > element.
> > I'd also offer this context help for popular error messages
> i.e. if the
> > MySQL server refuses the username / password.
>
>
> I definitely support this idea of context help, using the /lang files.
>
well i would use javascript if possible as well, but do you mean just using
an alert()?
i'd rather open a new window each time the user clicks on the ? instead of
sending all the strings with the page when he opens it so i can just display
them as a message. because otherwise we'd really have to write _very_ short
helptext or we would be sending a lot of helptext data which only few users
will ever see.
which is also why i wouldn't put them in the normal lang files - these get
included on every page, so with every page we'd be putting every available
shorthelp for all pages ....
Hi List,
Just a quick note to say I won't be around until Sunday evening. I've got
a business trip combination mini-vacation I need to make.
I'm leaving for it shortly.
All of the SQL parser should work fine.
I know of exactly one case it doesn't format properly at the moment.
INSERT/REPLACE ... SELECT
That will require a bit of reworking, so i'm leaving it for 2.3.1.
The only think left for the parser is writing a little bit of
documentation, so that is easy to do for the -rc4 release.
Enjoy your weekends, everybody.
Bye!
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
Just an addendum: "ob_flush()" is used in
"sqlparser.lib.php3" with no test but it requires
PHP >= 4.2.0.
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi List!
>DEBUG_TIMING and the strange order of function
>declaraction inside that block is related to my testing
>harness for the SQL Parser
OK.
["trigger_error" problem]
>This is a problem actually. I don't want to terminate the
>running of the page just because my SQL Parser can't
>handle something in the query. I wanted to just print out
>a message as to why my parser failed and continue
>execution of the page contents.
OK, the we may think about a way to emulate it under
PHP3.
["print_r" problem]
>I've changed that to just return the array for now, and I'll
>print it out from my test harness instead.
Fine.
["gzcompress" and "gzcompress" problem]
>Just dumping the data base64 encoded got really big, so I
>was just running it thru gzcompress before doing the
>base64 encoding.
OK but but should only do this if the "gzcompress"
function is usable ie
if (PMA_PHP_INT_VERSION >= 40001 && @function_exists('gzcompress')) {
$encodedstr = nl2br(chunk_split(base64_encode(gzcompress($debugstr,
9))));
} else {
$encodedstr = nl2br(chunk_split(base64_encode($debugstr, 9)));
}
>The linux kernel has a 'BUG()' call. For some of our
>PMA code, a similar thing would actually be a
>very useful function call.
Very interesting idea :)
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
