[Meinolf]

'peterlaursen' wrote:

But we will also check if this particular issue can be resolved more easily and if either solution can be pushed into next release cycles (9.1 or 9.2)

Hello,

this issue is still unsolved in version 9.3!

original index:

…

SPATIAL KEY `geometrie` (`geometrie`)

…

History of duplicate table operation:

/*[16:09:36][7 ms]*/ SHOW FULL FIELDS FROM `se`.`bplan_alle_copy`;

/*[16:09:36][1 ms]*/ SHOW TABLE STATUS FROM `se` LIKE 'bplan_alle_copy';

/*[16:09:43][1 ms]*/ SHOW KEYS FROM `se`.`bplan_alle_copy`;

/*[16:09:43][7 ms]*/ CREATE TABLE `se`.`bplan_alle_copy_copy` ( PRIMARY KEY(`file`),KEY `overlay`( `overlay` ), KEY `origfile`( `origfile` ), KEY `plantyp`( `plantyp` ), KEY `geometrie`( `geometrie` (32)))ENGINE=MYISAM COLLATE = latin1_swedish_ci COMMENT = '' SELECT `file`, `geometrie`, `overlay`, `imagetype`, `subsample`, `sub_minscale`, `sub_maxscale`, `resample`, `res_minscale`, `res_maxscale`, `origfile`, `plantyp` FROM `se`.`bplan_alle_copy` WHERE 1 = 0;

When will it be solved?

M. Asshoff

[Meinolf]

Thanks,

one additional hint on this:

A popup should be avoided, when only non geometry fields are edited, otherwise it would be annoying!

Or just exclude pure geometry fields from beeing shown and handeled by result/data tabs, but selects like astext(geometrie) should be able like now.

peterlaursen wrote on Feb 11 2009, 11:44 AM:

That is also what we are discussing now! Whenever a table or result set contains a spatial datatype any attempt to INSERT/UPDATE (from data or result tab respectively) should popup an error box and link to an explanation (a page in the CHM).

The developer team is analysing how complicated it will be!

[Meinolf]

Hello,

excuse me, I did not mention, that I only edited non-geometry fields. It was clear to me, that I can not edit geometries in result/data grid, of course.

peterlaursen wrote on Feb 11 2009, 10:04 AM:

You also can edit all columns that are not spatial by editing from the RESULT tab. If you have col1, col2, col3 and col4 and say that col3 is spatial and col1, col2 and col4 are not, then first execute “SELECT col1,col2, col4 …”. The result tab can now edit the col1,col2 and col4 columns.

We still used this alternative, when we need it, but allways have to keep this problem in mind when working with myisam and SQLYog, thats too faulty.

peterlaursen wrote on Feb 11 2009, 10:04 AM:

However we should not crash, and we should simply not touch data we cannot handle. If you could provide a test case we could look deeper into it.

That's the easiest way to get out of this problem:

SQLyog should not create updates for geometry fields when editing in the result/data grid.

Can this be implemented easily?

Thanks for your quick response

[Author]

Posts