Hi List!
Rainer Reitz wrote:
>I get the Error-Message 'No SQL Query' for even
>a simple statement like 'SELECT * from ...'.
>Creating and maintaining a database or table is
>possible, only if I run a SQL query, I always
>receive this nasty message.
- Which phpMyAdmin version are you using?
- Which server on which OS, which PHP version?
- Which browser on which OS?
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
On Thu, 1 Aug 2002, Lo�c wrote:
> >With the parser bug system, both loic and rabus have
> >seen the bug reports and asked what they actually are.
> Well indeed I knew what they are but since I can't use
> PHP at work and the live demo hasn't been updated I
> can not decode it.
Ok, it's updated now.
If you have Perl it is really easy to do the same behavior as well.
> BTW here is a revised version of this script (XHTML fix,
> PHP3 compatibility and so on). Could you test it, update
> the CVS tree if it works and update also the live demo.
Merged in CVS and the demo tree is updated.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
> This howto.html could have just a link to Documentation.html,
> usage tips
> section :)
>
> Marc
yes, it could... but i am also thinking of trying to get users ( != devs) to
write some howtos - that guy that asked about the pma book for example... i
talked a little to him, ended up doing some screenshot of how it should
work... i'd like to include stuff like that and encourage 'normal' users to
write some text for that - we know how it works, so we should be the ones
who write the dokumentation.html, but newbies might understand text that has
been written by a newbie (and only revised as little as needed by us)
easier.
just like the howtos you'd find in the linuxdoc.org - they usually don't
tell you the details - if you want to set up something quick you just do as
they did without wondering about what is actually happening there.
Regards
mike
ok, i see that we should keep the documentation in one file.. but
considering some userquestions on how use the query editor, i am wondering
if we should possibly just take the usage-tips out of this file and put them
in a howto.html - chances are that users who don't need to set up pma
themselves will not read the doku, and even if they do stop way before they
encounter the usage tips. having a file called howto.html might raise some
more interest.
--
Mike
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
