Как запросом добавить блок записей с требуемой последовательностью значений ключевого поля?
Мне нужно из старой формы добавлять позиции блоками условно с позиции А=10`000, а в новой форме начиная с поз. Б=10`000`000.

Изначальный запрос имеет вид


Т.е. количество записей определяется списком выбранных товаров.
Для одной записи вставить нужный id не проблема, как сделать так же для пачки?

Можно ли применить переменные

да, просто добавьте значение переменной (id пачки) в условие select

не пойму как в одном выражении инициализировать переменную и реализовать инкремент

@id:= 10000 ;
select @id:=@id +1;

можно пример набора, который надо получить?
речь о SQL, а вы о каких-то формах, блоках и пр.

аммм... MySQL не приходилось вплотную, но разве так не сработает?

INSERT INTO new_table (id, ...) SELECT id+9990000, ... FROM old_table WHERE ...

>DQ   (10.10.14 23:08) [4]
верная дорога в ад, одобряю
два запроса начинают работать одновременно, и - вуаля

Чего не так-то? На SQLServer'е десятки раз так копировал, и во временные таблицы и в другую БД - и всё в порядке.

> Кщд ©   (10.10.14 23:43) [5]

С виду все нормально. об чем спич?

> DQ

тс надо не скопировать из откуда-то, а разпараллелить вставку из старого и из нового. С разными ID
вообще, затея бредовая :(

>turbouser ©   (11.10.14 15:00) [7]
>С виду все нормально. об чем спич?
получать новый ID виде: IDNew = IDOld + const, - в многопользовательской среде чревато коллизиями
зачем выдумывать велосипед с квадратными колёсами, когда есть спец. инструменты для генерации ID?

> Кщд ©   (11.10.14 16:12) [8]


> получать новый ID виде: IDNew = IDOld + const, - в многопользовательской
> среде чревато коллизиями

так у DQ этого нет
там просто из одной таблицы в другую. причем весьма глупо

> Кщд ©  

аааа перечитал. пепел на мою голову :(

Я не генерирую "новые ID", тем более с многопользовательской... Останавливаем программу использующую БД, меняем данные, запускаем обратно.

> разпараллелить вставку из старого и из нового. С разными ID

В [1] не вижу ничего похожего. Дословно понял ТЗ так: надо единократно поправить данные в БД таким-то образом: были id с позиции такой-то, нужно поменять чтоб были с начиная с позиции такой-то, т.е. грубо говоря увеличить id у группы строк на некоторое число. Знаю похожую ситуацию. Написал рабочее решение. Если это не то что нужно ТС - то уже отдельный разговор, давайте ждать от него пояснений.

>Я не генерирую "новые ID", тем более с многопользовательской..
и
>DQ   (10.10.14 23:08) [4]
>INSERT INTO new_table (id, ...) SELECT id+9990000, ... FROM old_table WHERE ...

не согласуется
в общем, сам такой подход - ущербен
оставьте генерацию ID - базе

Нет никакого "подхода". Ну бывает что данные повредились. И нужно скопировать данные с конкретными id или изменить id. А после того как данные исправлены - разумеется пусь генерирует сама, никто не собирается за неё это делать.

Кщд ©   (11.10.14 17:52) [12]

Нам до сих пор неизвестно, что хочет автор ветки :)

Автор ветки хочет в новой форме при добавлении нескольких изделий запросом генерацию ID начиная с Б, чтобы в старой форме генерация продолжалась с А.

При добавлении одного изделия проблемы нет.
Затруднение при добавлении нескольких изделий.

Вопрос копирования не ставился, но существует.
Только не из old_table, а из себя в себя.
Регулярно требуется повторять заказ клиента.

>Дмитрий   (13.10.14 16:22) [15]
автор, пример
автор, на SQL
автор, про ваши "формы", "изделия" и пр. нам невдомёк

автор, шаблон примера:
1. было так. добивался этого эдак (код);
2. хочу, чтобы было вот так.

Ранее я никак не добивался "двухслойной генерации".
Используемый запрос я привел, он совершенно обычный, без извратов с генерацией.
Там  существенен только список ключей- идентификаторов.




Собираюсь реализовать ее для одиночных записей как запрос



Хочу (получив предварительно или непосредственно в запросе) генерировать последовательность нескольких ключей и вставлять их в таблицу.
Количество новых записей (и ключей) соответствует количеству кодов в списке



Очень желательно вставлять генерируемый ключ не в одно, а в два поля




> Кщд ©   (11.10.14 17:52) [12]
> DQ   (10.10.14 23:08) [4]>INSERT INTO new_table (id,
> ...) SELECT id+9990000, ... FROM old_table WHERE ...не согласуетсяв
> общем, сам такой подход - ущербеноставьте генерацию ID -  базе

интересует копирование нескольких записей со сдвигом значения ключа

>Дмитрий   (13.10.14 17:39) [17]

select max(id) + 1

так делать нельзя в многопользовательской среде

>интересует копирование нескольких записей со сдвигом значения ключа
для чего?
вам необходимо определять к какому блоку принадлежат записи, и вы собираетесь делать это по диапазону?

> Кщд ©   (14.10.14 09:34) [18]
> >select max(id) + 1
>так делать нельзя в многопользовательской среде

отчего ж нельзя,
в случае чего просто будет ошибка добавления записи

> [19] Дмитрий   (14.10.14 17:58)

- Нельзя переходить дорогу на красный свет.
- Отчего ж нельзя, в случае чего просто собьёт машина.

>Дмитрий   (14.10.14 17:58) [19]
а, вы из упорных
тогда можно)

А вот теперь я вижу что правда не так понял что нужно. И присоединяюсь что так делать нельзя.
То что я ранее писал только для исправления повредившихся данных. А обычно на значение id записи не обращают внимания, и уж точно не добиваются конкретных значений. Это просто любое уникальное число. По нему обычно не фильтруют, не сортируют, только связывают данные.

Поясните что есть:
 "новая форма"
 "старая форма"
 "изделие"
 "слой"
 "двухслойная генерация"
А так же зачем именно влиять на порядок id. Какая разница на их величину и подряд ли они или вразнобой?

в общем-то, плевать на величину, подряд они или "вразнобой"
первый вопрос в том, чтобы диапазоны id не пересекались
второй вопрос в возможности вставить сгенерированный id в несколько полей сразу.

причина желания в том,
что бд изначально была на акцессе,
моя задача перевести ее (в фоновом режиме) на mysql без остановки производственного процесса,
в том числе, продолжая добавлять новый функционал, требуемый руководством

в настоящее время, некоторые таблицы дублируются в акцессе и мускуле
новые поля добавляются в дополнительные мускульные таблицы
в старой форме при сохранении записи происходит дублирование из акцесса в мускул
в старой форме генерация id записи об изделии берется из акцесса
в новой форме генерация id берется из мускула

при одновременной попытке использовать обе формы (что потребуется в процессе тестового периода использования новой формы) неизбежно будет случаться накладка, когда один и тот же id изделия в акцессе и в мускуле привязан к разным заказам, с затиранием в процессе сохранения

при отсутствии других вариантов думаю вынести генерацию в диапазоне от 0 до 1'000'000 (условно) в доп.таблицу.

>при одновременной попытке использовать обе формы (что потребуется в >процессе тестового периода использования новой формы)
введите доп. поле-флаг (0/1): старая/новая форма.
если форм несколько, введите поле id-формы.
ID оставьте автоинкрементом и не вспоминайте о нём, пока не понадобится добавлять ограничения ссылочной целостности.

и как мне поможет поле-флаг?
менеджер вместо добавленного им изделия,
обнаружит какую-то хрень, добавленую его начальником или мной в процессе тестирования
потому, что в разных формах были сгенерированы одинаковые id
и более поздняя запись была автоматически продублирована в акцесс, затерев раннюю

>в старой форме при сохранении записи происходит дублирование из акцесса в мускул
признак "запись из Access" пишется в доп. поле

допустим, что таким образом синхроннизацию таблиц я отключу
что дальше с этими записями делать?
их только удалить,
нормальный рабочий процесс с ними будет не возможен

>Дмитрий   (16.10.14 15:50) [27]
>нормальный рабочий процесс с ними будет не возможен
мне задание на дом: угадать, почему невозможен?

уже две страницы из вас вытягивают информацию - но вы же партизан
опишите, что и в какой последовательности у вас происходит

Да, нужно подробнее. Может удобнее сделать две отдельные таблицы для mysql и access, а после сделать view. Ну или в одну и там дополнительные колонки original_id и db_id.

таблиц не две, а больше
две таблицы: заказы и изделия (соотношение 1:М) имеются и в акцесс, и в мускуле
и должны быть синхронизированы
кроме этих двух таблиц имеются еще несколько таблиц (только в мускуле)  связанные с т.изделия по id
* контроль (даты стадий производства) - (соотношение 1:1)
* компоненты - (соотношение 1:М)
...

к этому имеется изыск со связью т. размеры  по полю sizeID,
которое может быть как равно id текущей записи, так и не равно

на акцессных таблицах основана пачка отчетов и печатных форм
основная моя линия - замена операций добавления-модификации-удаления акцессных таблиц соответствующими операциями с мускульными таблицами
с последующей синхронизацией во второй базе
в дальнейшем, планирую заменить в акцесс таблицы ссылками (связанные таблицы из одбс-источника) на аналогичные в мускуле

умываю руки
успехов

программиста вам нужно...

но если суть "извратится" то - в access id автоинкремент с 1 (если не менялось дефайлтное), в mysql сделать id  автоинкремент  начиная с -maxint (минус максинт). вуаля. пересекаться не будут.

спаси вас бог, добрые люди