Issue With Inserting A Row At The Bottom Of Table Data Grid

[vygi]

Let's do following:

1. create a table with an unque non-autoincrement index or primary key, eg:

CREATE TABLE test (


n int(10) unsigned not null default 0,


s1 varchar(255) not null default '',


s2 varchar(255) not null default '',


PRIMARY KEY (n)


)

(alternatively you can try it with your own table)

2. make sure you have 10-20 rows of data in this table, incl. a row with default primary key value (in our case n=0)

3. switch to the Table Data tab and make sure that you have scroll bar on the right (table data tab is not large enough to show all rows at once)

4. now go to the last row, double-click on the second cell (“s1”, NOT n) and type something in.

You will see that you're typing almost outside od data grit, at the very bottom of the data grid.

(SEE 1ST SCREENSHOT)

5. Press TAB to switch to the next column (s2). The row you're editing disappears at all. Now it is actually not visible because it is somewhere below the data grid.

6. try to move (with the mous) the scroller on the right side of the grid or clisk of their arrows.

You wil get a large number of “Suplicate entry” errors, at least 5 or 10 if you're quick enough to releas the mouse, or up to several hundreds of them!

(SEE 2ND SCREENSHOT)

Looks like SQLyog tries to insert this (unfinished) row as soon as you try to scrol to get your row back to the screen.

And it really inserts it when there is no key conflict. This also may cause problems (eg. in the case that you have some triggers and they start to work on unfinished rows).

Vygi

ADDENDUM: I have checked this in Result grid and SQLyog tried to insert a row on every scroll attempt which is not correct, I think.

[peterlaursen]

I tried to follow your instructions, but failed in doing so!

5. Press TAB to switch to the next column (s2). The row you're editing disappears at all. Now it is actually not visible because it is somewhere below the data grid. NOPE it does not disappear!

6. try to move (with the mous) the scroller on the right side of the grid or clisk of their arrows.

You wil get a large number of “Suplicate entry” errors, at least 5 or 10 if you're quick enough to releas the mouse, or up to several hundreds of them! Not either, but as first step was not reproduced that could be why!

Here it looks a little bit different. See attached. What happend to that 'brick' with an asterix (*)

Did I miss something?

[vygi]

peterlaursen wrote on May 3 2006, 09:48 AM:

I tried to follow your instructions, but failed in doing so!

5. Press TAB to switch to the next column (s2). The row you're editing disappears at all. Now it is actually not visible because it is somewhere below the data grid. NOPE it does not disappear!

6. try to move (with the mous) the scroller on the right side of the grid or clisk of their arrows.

You wil get a large number of “Suplicate entry” errors, at least 5 or 10 if you're quick enough to releas the mouse, or up to several hundreds of them! Not either, but as first step was not reproduced that could be why!

Here it looks a little bit different. See attached. What happend to that 'brick' with an asterix (*)

Did I miss something?

hmmmm… don't know…

do you have a scrollbar at the right?

and also do you already have a row with default primary key value? otherwise there will be no primary (or unique) kay conflict and therefore no error messages.

I also tried it in the Result row: when I clisk “add row” (green “+”), a new line appears and remains visible, so there is no issue at the 5th step. But when after them I try to scroll — SQLyog tries to insert the row being edited, and I again get those errors.

[peterlaursen]

I have a scroll-bar and I used your table definition and filled data into it so that there were more rows than could be displayed.

The asterix symbolizes non-saved rows, I think! I think this is part of a the windows API, but Ritesh must explain.

It is similar in Access and OpenOffice Base when you open a table. Don't you have it there either?

[vygi]

peterlaursen wrote on May 3 2006, 10:09 AM:

I have a scroll-bar and I used your table definition and filled data into it so that there were more rows than could be displayed.

The asterix symbolizes non-saved rows, I think! I think this is part of a the windows API, but Ritesh must explain.

It is similar in Access and OpenOffice Base when you open a table. Don't you have it there either?

No, Access works fine, I can scroll as long as I want and Access does not save not finished rows.

BTW asterix in Access means new (empty) rows and it changes to “pen” (and another empty asterix row appears) when you start o edit, so empty (not existing) = asterix and not saved = pen in Access.

[peterlaursen]

SQLyog uses no pen. But when you start entering data in the asterix row another asterix row is displayed below. When moving cursor from the row you have been writing asterix changes – indcating that row has been saved!

Now Ritesh must be able to tell/guess whether the missing asterix and the strange thing you reported is the same issue.

@vygi ..

check this issue on another computer. You had 5 licenses at the office?

[Ritesh]

I have been able to reproduce Problem #4 and it has been fixed.

Working on #6 but I am will be releasing BETA 4 now which will have the crash and the trigger export issue fixed. Will probably fix #6 in BETA 5.

[peterlaursen]

Code:

Will probably fix #6 in BETA 5

To me it looks more like vygi's PC needs an OS repair or reinstall ?!

[vygi]

peterlaursen wrote on May 3 2006, 11:12 AM:

Code:

Will probably fix #6 in BETA 5

To me it looks more like vygi's PC needs an OS repair or reinstall ?!

Why this?!…

[format c:] <-- execute this to get new OS

[peterlaursen]

did you notice the '?!`. What I wrote was mostly meant as an open question (to Ritesh primarily) if the function depended on some OS routines, that did not function on your Windows installation and in case so what could be the reason for this.

Thanks for offering me a new OS .. but I'd prefer to have my new monitor first!

[Ritesh]

Nope. It is not dependent upon any routines. We are working on it and I am sure by tomorrow, we will be able to reproduce the issue if we work diligently.

[Ritesh]

http://www.webyog.com/forums/index.php?sho…view=getnewpost fixed problem #4.

[Author]

Posts