Hi,
starting with MySQL 5.0.23, SHOW CREATE TABLE includes the
AUTO_INCREMENT next value, just after the ENGINE clause.
We had a "Add AUTO_INCREMENT value" option in table operations and db
operations.
So I suggest:
- for 5.0.23+, the "Add AUTO_INCREMENT value" checkbox be removed from
table operations and db operations dialogs. The same functionality is
now being provided automatically in the CREATE TABLE statement
- for 5.0.22-, I would also prefer to remove these checkboxes
For all MySQL versions, I guess that during a copy, the majority of
users want to copy also the AUTO_INCREMENT value. If it's not the case,
they can always go to the copied table on Operations and change the
value in "Table options".
If we still want to provide this checkbox, well for 5.0.23+ we would
have to examine the statement and remove the AUTO_INCREMENT clause.
Marc
Hi,
I think we could freeze the messages for 2.9.0 and prepare for 2.9.0-beta1.
Also, I might release 2.8.2.1 tomorrow (not from QA_2_8) with backports
of these fixes:
- detect new config.inc.php (need to close all browser windows)
- IE6 on IIS blank frame (trivial fix but will be appreciated by users)
Anything else urgent to backport?
I don't think we should call this 2.8.3.
Marc
Hi,
i hope tis will put an end to all this font size issues
pls checkout latest CVS HEAD and test
you can now configure font size on the main page, it will be stored
inside cookie pma_fontsize
--
Sebastian Mendel
www.sebastianmendel.de
Hi,
in 2.7.0-pl2/libraries/select_theme.lib.php we did
if ($theme_generation != PMA_THEME_GENERATION)
continue; // different generation
if ($theme_version < PMA_THEME_VERSION)
continue; // too old version
---------------------------
Since 2.8.0 there is no verification against PMA_THEME_GENERATION and
PMA_THEME_VERSION in PMA_THEME::loadInfo(), why?
Also, I would prefer if we go back for 2.9.0 to this
$theme_version = 2;
$theme_generation = 2;
instead of
$theme_full_version = '2.8';
it would make generation and version comparisons easier in loadInfo().
Marc
Hi guys!
I took the liberty to drop a small comment here:
http://blogs.adobe.com/mikepotter/2006/07/using_php_and_f.html
Their blog has a quite high responsivity in the developer community, so maybe
some people might get curious and drop by for active help. I guess helping hands
are always a good thing. ;)
Best regards,
Garvin
--
++ Garvin Hicking | Web-Entwickler [PHP] | www.garv.in | ICQ 21392242
++ Developer of | www.phpMyAdmin.net | www.s9y.org
++ Make me happy | http://wishes.garv.in
Hi,
About this bug report (moved by me to support).
I don't understand what he means by "a latin1_swedish_ci field that
holds data which represents windows-1251 characters".
The test he suggests today works as he says. I used Windows's charmap to
choose the cyrillic character O with a vertical bar (represented here
http://en.wikipedia.org/wiki/Cyrillic_alphabet by value 424). I inserted
this character via a small application as he suggests. With the small
application (forcing a windows-1251 charset) I see the character
correctly. In phpMyAdmin, using an hex transformation, phpMyAdmin 2.8.2
displays c3 b4. Without a transformation, it's not the right character.
Can someone explain me what is this c3 b4?
Because in win 1251 http://en.wikipedia.org/wiki/CP1251
this O vertical bar character should be D4.
Note: In the thread I made a test with what I think is the proper way of
inserting cyrillic characters.
Marc