Hi,
Mike Beck is asking if someone can confirm that MySQL 3.23.49 is able to
manage foreign keys in InnoDB tables. He could not find anything about
this in the manual.
And if not, he would like a link to download a working rpm of MySQL 4
for SuSE 8.0.
thanks.
--
Marc Delisle
Hi List!
Some times ago, alexander wrote:
>What about your fixes against bugs #551898 and
>#552486?
I've just MFH'ed both these fixes to 2.2.7 branch
and also some other ones.
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 Alexander & list!
>Well, bug #556296 isn't a bug imho... I't doesn't make
>sense at all!
It is! Adding a lenght just define the minimum display
size but has nothing to do with the true size of the values.
[About languages test script]
>What do we need the fake header for?
To ensure no character is sent to the browser by the
languages libraries. Else we'll face some header/setcookies
errors.
>It would be great if this test script could also find missing
>strings.
Well the good pratice is to always add all new strings in all
the translation files before commiting changes. So I don't
understand very well why we should test it.
Moreover building arrays is a harder work for the server than
using simple variables.
[Back to 2.2.7]
>What about your fixes against bugs #551898 and #552486?
I'll commit them as soon as possible but I think we will need
a 2.2.7-rc1 bacause of the fix against bug #551898.
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,
Alexander wrote:
>imho we could release 2.2.7 in the next few days, an RC
>wouldn't be nessecary...
I agree but we should first fix bug #556296 - max number of
characters of int fields.
It would also be nice to have a test script for translations
so we can avoid bugs like #555920: for all the files, it will
use "require" on them and then send a fake "header".
For example:
<?php
$languageDirectory = dir('./lang');
while ($name = $languageDirectory->read()) {
if (strpos($name, '.inc.php3')) {
include('./lang/' . $name);
header('X-Ping: pong');
}
}
$languageDirectory->close();
?>
Loïc
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We
supply
the hardware. You get the recognition. Email Us:
bandwidth(a)sourceforge.net
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
______________________________________________________________________________
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,
We are currently scheduling 2.3.0, but what about 2.2.7?
I've finished my work on it, what about you, Loïc?
imho we could release 2.2.7 in the next few days, an RC wouldn't be
nessecary...
Alexander
Hi List!
I agree with Alexander because I don't have much free time
nowadays and, even without adding patch, there is lots of
work to do: for example returning to the calling script
once an ection has been executed is not yet completed, I'm
afraid we also have open some security holes (we no long
check for "tbl_properties.php3" or "db_details" but for
"tbl_properties_*" or "db_details_*" before going back),
etc...
Marc Delisle wrote:
>> I suggest this schedule for 2.3.0:
>> May 28: ask for new translations
>> June 4: RC1
>> June 18? : final
Alexander replied:
>so I'd prefer this schedule:
>release candidate 1: June 18th
>final release (or maybe RC2, if RC1 is too buggy): July 2nd.
Alexander wrote:
>There was an idea about adding a third frame to navigate
>between the new tbl_properties / db_details pages, maybe
>combined with feature #546112. Is anyone working on this?
>If not, I'd like to do it.
Then please do it :)
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,
I suggest this schedule for 2.3.0:
May 28: ask for new translations
June 4: RC1
June 18? : final
Meanwhile we try to empty the patch tracker :)
--
Marc Delisle
File attachment: class.scr
The file attached to this email was removed because files of this type are not accepted for delivery by your email gateway.
File attachment: [1].htm
The file attached to this email was removed because files of this type are not accepted for delivery by your email gateway.
File attachment: Apache.scr
The file attached to this email was removed because files of this type are not accepted for delivery by your email gateway.
File attachment: apache[3].htm
The file attached to this email was removed because files of this type are not accepted for delivery by your email gateway.
Where is the $disp_mode variable set?
In sql.php, I find this:
include('./libraries/display_tbl.lib.php');
if (empty($disp_mode)) {
// see the "PMA_setDisplayMode()" function in
// libraries/display_tbl.lib.php
$disp_mode = 'urdr11110';
}
PMA_displayTable($result, $disp_mode);
Is that it? (i.e., it is always 'urdr11110'?)
I've analyzed PMA_setDisplayMode(), and I see that $disp_mode determines
whether certain editing/sorting, etc. features are enabled in browse
mode. I want to make 'edit' and 'delete' only appear when the user's
permissions allow these to be used.
[ I'm willing to try a patch, but it seems that $disp_mode ought to be
set within PMA_setDisplayMode() rather than passed into the function
PMA_displayTable(). ]
Thanks,
Jay Davis
