Hi Marc,

On Mon, Aug 27, 2001 at 02:21:07PM -0400, Marc Delisle wrote:

which bugs do you consider to be showstoppers?

don't know exactely right now (didn't followed the story the last days: too much work). There were something about the import of dumps not genereated by phpmyadmin, and something else about sql queries with some backquotes problem (from the users forum page as far as i remember).

Just also noticed a problem with the NOW() function: if it's set and there is a value in the field, it won't be updated. -> only if the field is empty. And as far as I remember, it worked in the past when I wrote this patch...

Voila, that's what I have in mind currently :) Will try to check that NOW() problem tonight or tomorrow, and make some more tests. And if I have your ok (with Loic and others here), we could release it tomorrow (on tuesday), and see what happens...

Greetings, Olivier

On Mon, Aug 27, 2001 at 11:40:06PM +0200, Olivier M. wrote:

On Mon, Aug 27, 2001 at 11:24:33PM +0200, Olivier M. wrote:

...

Voila, that's what I have in mind currently :) Will try to check that NOW() problem tonight or tomorrow, and make some more tests. And if I have your ok (with Loic and others here), we could release it tomorrow (on tuesday), and see what happens...

mmm, the problem seems to be worse that I first thought: seems that no funtion at all works when the data field is not empty. quite annoying to encrypt a password...

Correction: "when the data field is not empty and the data field not changed".

Ok, found the problem reason: Seems to be related to the new "fields_prev[]" variable... :

// No change for this column -> next column if (isset($fields_prev) && isset($fields_prev[urlencode($key)]) && ("'" . sql_addslashes(urldecode($fields_prev[urlencode($key)])) . "'" == $val)) { continue; }

that doesn't check if the function is set... not good! Replaced this part by:

// No change for this column -> next column if (isset($fields_prev) && isset($fields_prev[urlencode($key)]) && !empty($funcs[$key]) && ("'" . sql_addslashes(urldecode($fields_prev[urlencode($key)])) . "'" == $val)) { continue; }

And it seems to be ok now. If the one who made that (loic ? :) could check if it is ok, that would be nice thanks.

Btw, what is this $fields_prev[] information for ? (beside doubling the page size). In the case of an UPDATE in a table without id field ? I see that in the changelog: 2001-08-15 Loïc Chapeaux lolo@phpheaven.net [...] * tbl_change.php3; tbl_replace.php3; lang/*: Fixed bugs #444354 (Various backslash problems), #450906 (Disappearing + in data | 2.2.0rc4), #450374 (RC4: + becomes space) and the one with binary data reported by Steve in the mailing-list. but don't see exactely what is the fields_prev for ? (which bug ? :).

Regards, Olivier

I'm on it - looking at it - and hope to get some more tests done today or tomorrow - else we have to wait until more detailed info about this problem comes to our attention...

Kind regards Geert

----- Original Message ----- From: "Marc Delisle" DelislMa@CollegeSherbrooke.qc.ca To: phpmyadmin-devel@lists.sourceforge.net Sent: Tuesday, August 28, 2001 5:15 AM Subject: Re: [Phpmyadmin-devel] to delay or not to delay ?

"Olivier M." a écrit :

Voila, that's what I have in mind currently :) Will try to check that NOW() problem tonight or tomorrow, and make some more tests. And if I have your ok (with Loic and others here), we could release it tomorrow (on tuesday), and see what happens...

The "dump hangs" bug is the worse IMHO, but if we can't reproduce it easily, it could wait after 2.2.0.

So you have my OK :)

Marc

_______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel