INSERT INTO от същата таблица...

След питането за RecorLock сега се спънах в друг проблем:
Искам да копирам запис от една таблица в същата таблица (с промяна на едно от полетата, но това не е проблем).
Пускам
INSERT INTO Table1 (Field1, Field2) SELECT Field1, Field2 FROM Table1

и идва грешка 1066 - Not unique table/alias: Table1

Ей така пък минава, но само от промпта (през C++ API връща 1066):
INSERT INTO Table1 (Field1, Field2) SELECT Field1, Field2 FROM DB.Table1

Как се справяте с това?

В Oracle SQL този INSERT се изпълнява без проблеми. Но като гледам INSERT-а и грешката пробвай дали така ще стане:
INSERT INTO Table1 (Field1, Field2) SELECT t1.Field1, t1.Field2 FROM Table1 t1
и разбира се не трябва да имаш PRIMARY KEY constraint върху нито една колона или комбинация от колони от Table1.

А да беше казал за кой сървър иде реч?

Малко са тези които го поддържат между другото - освен Oracle друг има ли?

salle.online.bg/sig

За MySQL става въпрос - сега съм на тази вълна :-\\ (минаваме от Oracle на MySQL).

По повод забележките на Svircho (по горе): опитвах така (tbl.field), но не върви. А за primary key - полето е autoincrement, но за тестовете даже си направих специална таблица без primary key.

Ех, как не ми се иска да правя временни таблици и прочие кеч...

p.s. Както казах по-горе, в MySQL (през MySQL-Front) заявката минава успешно! Salle, това изненадва ли те (като питаше дали другаде освен в Oracle върви)?

Като се логна и не ще да ми поства съобщенията пустия Дир :-(((
Пише "Вашето съобщение е получено", ама най-горе излиза "Seeya" и после няма никой. От вчера само като нерегистриран мога да поствам...

Я дай малко повече подробности за това дето минава успешно.

Минава в смисъл, че не получаваш грешка или в смисъл, че работи?

Защото INSERT INTO table1 .... SELECT ... FROM table1...;

не се поддържа и няма и планове за това - трудно е да са гарантира 'цялостност' на таблицата особено като се има предвид, че трябва да работи със всички типове таблици.

Иначе какво толкова им се плашиш на временните таблици ... особено ако използваш CREATE TEMPORARY TABLE

Да не говорим пък, че най-често можеш да използваш и TYPE=HEAP

1. CREATE TEMPORARY TABLE temp SELECT <нещо бързичко>;
2. INSERT INTO temp SELECT <нещо друго сравнително бързичко>
3. SELECT <нещо много сложно и бавно> FROM temp;

В много случаи това дори силно ускорява нещата - първо защото можеш да оптимизираш поотделно заявките и второ защото "освобождаваш" таблиците по-бързо.

salle.online.bg/sig

Ето тази заявка не дава грешка и прави точно това, което искам (освен ако не залага подло някой капан за по-късно):

INSERT INTO Table1 (Field1, Field2) SELECT Field1, Field2 FROM DB1.Table1

(Обърни внимание на DB1, което е същата база)

А за work-around-а - сега ще пробвам. Има ли смисъл да дропна изрично временната таблица след като приключа с нея? Щото в моя случай връзката може да се позадържи активна доста дълго.

mysql> use t;
mysql> insert into b select * from t.b;
ERROR 1066: Not unique table/alias: 'b'

И не се случва нищо (т.е. таблицата си остава с колкото редове си е била)

Какво става при теб след:

SELECT COUNT(*) FROM table1;
INSERT INTO Table1 (Field1, Field2) SELECT Field1, Field2 FROM DB1.Table1;
SELECT COUNT(*) FROM table1;

Същото число ли получаваш или *2 ?
И какво казва:
SELECT VERSION();

salle.online.bg/sig

Преди да кажа резултата, да вметна, че направих работатат с TEMPORARY таблица и е много пъргаво (с HEAP щеше да е още по-добре, но имам един BLOB и не става)
А сега за резултата от това, което искаше да проверя:

SELECT VERSION() = 3.23.49-max-nt

SELECT COUNT(*) FROM table1 = 10
INSERT INTO Table1 (Field1, Field2) SELECT Field1, Field2 FROM DB1.Table1 (OK, no error)
SELECT COUNT(*) FROM table1 = 24 (!!!!!)

Ако обаче сложа и WHERE DB1.Table1.Field1 = <value>, или се вмъкват точно колкото трябва записи, или нищо (при една и съща стойност на <value>)

Веселичко.

Почвам да си мисля, че това е един от проблемите с Win и това дето не прави разлика между големи и малки букви в имената на файловете (разбирай имената на Базите и Таблиците)

Ще го препратя на Win - програмистите

Междувремменно ще ми направиш голяма услуга ако го пробваш със 3.23.52

salle.online.bg/sig

Значи това е един адски неприятен бъг във Win версиите на 3.23.x

Имената на базите се сравняват 1:1 т.е. има разлика м-у големи и малки букви. Както знаеш в другите файлови системи така и трябва да бъде, но Win не прави разлика (DB1 = Db1 = dB1 = db1)

В някои случаи това сравнение може да забие сървъра (mysqld) и поради това в 4.0 е променено.

Аз не се занимавам с Windows и затова е минало покрай мен.

Тъй, че както се казва в документацията това НЕ трябва да работи.

Доколкото помня SQL92 го забранява между другото. Не съм съвсем сигурен - трябва да проверя.

salle.online.bg/sig

Еееее, сега като каза за буквите, разбирам и защо в промпта "върви", а през API-то - не: в промпта поради мързел пиша само с малки букви, а в програмата за красота ръгам смесено. Й файловете на базата са с малки и главни букви :-\\

Иначе за версия 3.23.52 не мога да обещая експедитивност - малко ме е шаш да пипам точно сега, когато съм по средата на работата.
BTW, кой е препоръчителният начин за upgrade?