[peterlaursen]

And this table

Code:

create database if not exists `test`;
USE `test`;

/*Table structure for table `t1` */

DROP TABLE IF EXISTS `t1`;

CREATE TABLE `t1` (
 `id` bigint(20) NOT NULL auto_increment,
 `txt` varchar(50) default NULL,
 PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

does exactly the same when delete the single row in there (using HTTP)!

[peterlaursen]

Confirmed

with 5.02/5.03 I can insert and delete these data using HTTP, with 5.1 I can't.

EDIT: WRONG! Broken with 5.0!

The DELETE is not logged to HISTRY (@ritesh: why not?)

The inset looks like:

Code:

insert into `uploaded_mp_files` (“,“,“,“,“,“) values ( '24','test.jpg','','','2','502')

researching ….

[peterlaursen]

What does the DELETE statment look like in HISTORY pane?

[peterlaursen]

Does any of the the column-names in the table contain special (non-english) characters?

Could you please paste in (could be a sreen dump) of the exact error message!

It it exactly like Unknown Column '' … (empty string)

read this: http://www.webyog.com/forums/index.php?showtopic=1915

I can reporduce! But right now I can't upload an image (because of migration proces to another server)

If there is no Primary Key SQLyog generates SQL like

Code:

delete from `test2`.`lem_pl` where `lem`='æøå' and `code`='ÆØÅ' and `parent`='1' and `word_id`='2'

If there is a Primary Key SQL looks like:

Code:

delete from `test2`.`lem_pl` where `lem_id`='5341205'

In the above link I sometimes the the err msg *query is empty* when INSERTING data with Danish characters. That means such string looks empty after being tunneled. That would fully explain it!

If you can create a autoincrement PK with the table that will solve the problem.

I don't exclude there the is an issue with SQLyog (encoding transformation from SQLyog ANSI environment through tunneling to a non-ANSI environment). But I think there is an issue with MySQL/and or PHP too. Try follow the link to bugs.mysql.com in the thread I linked to. I have no problems with MySQL 3.23.58 and php 4.3.2. But with MySQL >= 4.0 and php 4.4.2 and 5.1.2 I have!

[peterlaursen]

@outland

It is a very bad idea to post the same in two different threads in the same forum. This is elementary netetiquette! Better post it ONE PLACE and post a link the second place!

And the reason for this is that the discussion will be devided between two threads, and users that don't know that will miss part of the discussion!

I shall therefore ask users who want to discuss this to go here:

http://www.webyog.com/forums/index.php?showtopic=1338

[peterlaursen]

Also remember to check for next version soon.

There is an issue with PKs involving timestamps that has been solved.

[peterlaursen]

Oh .. those details .. hard to remember.

It is only the PK that matters. the 'ordinary' indexes don't play a role.

I am always sure that this is an issue that has been fixed. But I simply cannot recall details right now. I think a checksums issue with 'unsigned'

Latest verison is 5.02. Filename sja502.tar.gz. Uploaded to server 12-12-2005.

Would you mind trying latest build if you don't have it

[peterlaursen]

Now …

suppose that a column contains (literal) '(NULL)'. It will then be displayed as (NULL). When saving it will be parsed as NULL .. and column has changed from '(NULL)' to NULL <_< Now that also applies if dispayed as NULL as I proposed. No difference. The whole problem is that any display is ambigious. NULL is nothing and a grid always contains something. Even an empty string is something!

This earlier proposal of mine

Quote:

an INSERT or UPDATE statement generated from DATA or RESULT panes should skip a column when:

3) cell contains a DEFAULT that is also a supported KEYWORD (CURRENT_USER etc)

even does not solve it. Because if you save a literal 'NULL' (using backquote = `NULL) and open it again it displays just like a NULL, and next you save it would become NULL.

Won't we simply need to display the BACKQUOTE for literal KEYWORDS (no matter if they are bracketed () or not) – to avoid that they become functional KEYWORDS after a save?

I am really sorry .. I don't mean to bother anybody.

Who invented that NULL (where is the hangman icon?) ?

[peterlaursen]

You have a PM!

[peterlaursen]

I got an idea to effectivize it …

1) First create a table with a subset of the data you'll need on the one host

CREATE TABLE smalltable SELECT … WHERE …

2) Now you can copy smalltable to the other host with SQLyog

3) And do as you used to ..

INSERT INTO … () SELECT FROM smalltable WHERE

4) And drop smalltable on both hosts

You cannot automate it with pure SQL.

[peterlaursen]

@sathyaw

I saw your face at the Forums, looking like 😡

No need to be angry anymore! The sync-with-timestamp-PK issue should be fixed with 5.1 BETA (works OK here). Can you confirm?

[peterlaursen]

I doubt if you've read my last post with your latest writing.

If default is defined 'CURRENT_USER' it should not become CURRENT_USER (aka root@localhost). This is why I think we should do with CURRENT_USER and UTC_TIMESTAMP as with NULL – enclose it in brackets () and parse for it like we allready parse for (NULL).

This 'feature' may at first sight look 'smart' but it is wrong actually, and not at all useful as SQLyog is the only client that does like this.

Quote:

Only CURRENT_TIMESTAMP is applicable

I think localtimestamp also is applicable as DEFAULT. Even with 'on update localtimestamp'. At least you can run it from commandline like this (but it is transformed by the server as of 5.1.6).

[peterlaursen]

Now this is funny!

default for `mynull`is 'CURRENT_USER' (literal)

however when SQLyog saves it does not quote and thus it becomes CURRENT_USER (root@localhost)

SQLyog has enhanced the functionalities of MySQL 😮

funny .. yes! But not very good! I think we will have to display as (CURRENT_USER) and (UTC_TIMESTAMP) and to parse for (CURRENT_USER) and (UTC_TIMESTAMP) like for (NULL) when saving from the grid!

[peterlaursen]

Also UTC_TIMESTAMP generates error 1064 with DEFAULT like

alter table `test2`.`testtable` change `myts2` `myts2` timestamp NOT NULL default UTC_TIMESTAMP;

hmmm.. here is something to keep an eye at! We will se changes with this stuff as MySQL 5.1 'grows', I'm afraid!

[peterlaursen]

Quote:

Fixed in BETA 2 development tree.

What is fixed?

If I try use DEFAULT CURRENT_USER form SQLpane I get error 1064.

Do I do something wrong?

[Author]

Posts