Как переместить запись из одной таблицы в другую нажатием кнопки |Удалить| на форме в Access

@nevada174 · Регистрация: 05.10.2014

Студворк — интернет-сервис помощи студентам

Уважаемые форумчане!
Дано: Имеем две идентичные таблицы "Главная" и "АРХИВ". Имеем форму в которой отражаются данные таблицы "Главная". На форме имеется кнопка |Удалить|. При удалении записи в списке на форме данные из таблицы "Главная" удаляются безвозвратно.
Условие: Необходимо при нажатии на кнопку |Удалить| данные из таблицы "Главная" экспортировать в таблицу "АРХИВ" которая в свою очередь ни как не связана с "Главной".
Вопрос: Как реализовать такой каприз?

@snipe · 08.10.2014, 13:56

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

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

mobile · 08.10.2014, 14:02

nevada174, для перемещения записи в АРХИВ необходимо преобразовать в т.АРХИВ поле номера из счетчика в длинное целое. Иначе свой счетчик в архиве буде содержать свои, совершенно отличные от исходных значения.
2. Копирование можно выполнить запросом

SQL
1
2
3
INSERT INTO АРХИВ
SELECT * FROM [ООП УСЗН - Главная]
WHERE [Номер п/п]=forms![Отдел опеки и попечительства - Главная]![Список БД]

3. Удаление запросом

SQL
1
2
DELETE * FROM [ООП УСЗН - Главная]
WHERE [Номер п/п]=forms![Отдел опеки и попечительства - Главная]![Список БД]

После выполнения запросов список надо обновить

Visual Basic
1
Me.[Список БД].Requery

Но я бы не стал переносить в отдельную таблицу. Слишком много возни, если вдруг эти записи понадобятся. Гораздо проще завести дополнительное логическое поле в [ООП УСЗН - Главная] и когда запись становится "не нужной", ставить в этом поле галочку. А для формы использовать в запросе условие, где это поле=False

@nevada174 · 08.10.2014, 14:21 **[ТС]**

Спасибо отозвавшимся форумчанам!

В применении Логического поля в таб. "Главная" не совсем приятная вещь в плане того, что при экспорте таб. "Главная" в Excel ставшими (на момент экспорта таблицы) не нужными записи на ряду с нужными экспортируются, что не облегчает дальнейшую обработку информации непосредственно в Excel. Но и удалять безвозвратно данные тоже не есть хорошо. Как обычно бывает, сегодня инфа не нужна, а через пол года появляется необходимость в их восстановлении. Вот и приходится перегонять из одной табл. в другую.

mobile · 08.10.2014, 14:58

Сообщение от nevada174

при экспорте таб. "Главная" в Excel ставшими (на момент экспорта таблицы) не нужными записи на ряду с нужными экспортируются, что не облегчает дальнейшую обработку информации

Это элементарно обходится. Вместо таблицы, надо экспортировать запрос с условием False на поле признака.

@boby104 · 08.10.2014, 15:12

Согласен с мобайлом
Перегонять данные в другую (архивную) таблицу имеет смысл, когда нужно фиксировать все изменения записи в разрезе дат и пользователей
у вас это пока не предусмотрено.
поэтому поля достаточно ... не хотите логического добавьте текстовое - это поможет ранжировать записи по их статусу
например Новая, Включена в обработку, Утверждена, Требует подтвержения и Удалена

@nevada174 · 08.10.2014, 16:57 **[ТС]**

Всем спасибо!
Поэксперементирую с полем по советам mobile и boby104

@nevada174 · 08.10.2014, 23:40 **[ТС]**

Пока ставлю эксперементы накидал такую реализацию:

mobile · 09.10.2014, 00:28

Ну, что ж, раз Вы избирательно слушаете рекомендации, то вот Вам вариант для эксперимента:
1. В форме удалите запись с максимальным номером - Суслопаров Алексей Викторович с номером 6.
2. Сожмите базу данных. Это нормальный рабочий прием для сборки мусора
3. Снова зайдите в БД и занесите в таблицу другого человека или нескольких
4. Опять удалите запись с номером 6
Теперь Вы ожидаете что в архиве будет 2 записи. Зайдите и посмотрите

@snipe · 09.10.2014, 06:22

Не по теме:

Шарик: Я за ним полдня бегал что бы фотографию сделать
Матроскин: Погоди, ты еще за ним полдня бегать будешь
Шарик: это еще почему же?
Матроскин: Что бы фотографию отдать
(м/ф Каникулы в Простоквашино)

nevada174, вот у вас сейчас стоит задача поместить записи в архив и как вы изначально хотели это делать - перемещением в другую таблицу(о всех "прелестях" такого действа на пальцах объяснил mobile) но на практике возникнет обратная задача вернуть из архива записи - хотел бы я посмотреть как вы ее решите.
Принцип - на зло мужу сяду в лужу в данной ситуации не подходит
вам предлагают решение из серии дешево и сердито (максимально эффективное при минимуме затрат)
Более чем уверен что база ваша не такая громоздкая как Вам кажется на первый взгляд, я к тому что предлагаемое всеми решение для Вашей базы оптимальное
а именно
поставить индикатор того что запись архивная - это может быть что угодно Логическое поле которое просто показывает что запись в архиве, поле типа дата - если поле пустое то запись не в архиве если с датой то можно узнать когда поместили, текстовое поле - резолюция при внесении записи в архив или кто из юзеров поместил запись в архив
можно несколько полей в которые поместится инфа об архивации записи

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

в конце концов можно заморочиться с репликацией

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

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

@nevada174 · 09.10.2014, 08:06 **[ТС]**

mobile Теперь Вы ожидаете что в архиве будет 2 записи c номером 6

Точно так! В табл. "АРХИВ" поле [Номер п/п] не является счетчиком и не является ключевым, поэтому под порядковым номером 6 могут быть сколько угодно Суслопаровых или Зябликовых, а при восстановлении (чел. выбирается по фамилии имени отчеству или например по паспортным данным (да и живём мы с этими параметрами)) тот же Суслопаров займёт строчку в табл. "Главная" согласно номеру вновь присвоенному счетчиком. Но всё это лирика. Чтобы не изобретать велосипедов с мотором и подогревом сиденья хотелось бы увидеть "живой" кусок БД работающий с доп. полем (). СПАСИБО!!!

P.S. с доп. полем без применения в форме подчинённых форм, т.к. БД рабочая и переделавать.... проще новую сваять.

@snipe · 09.10.2014, 08:56

вот набросал на коленке

@snipe · 09.10.2014, 09:17

Сообщение от nevada174

от же Суслопаров займёт строчку в табл. "Главная" согласно номеру вновь присвоенному счетчиком.

вам просто сказочно повезло что у вас всего одна таблица и нету связей с другими таблицами
вот как только появится табла которая будет использовать id записи из таблы Главная вот тут и начнутся Ваши мучения

@nevada174 · 09.10.2014, 09:41 **[ТС]**

Именно так! БД создана в ДевяностоЛохматом году.

Добавлено через 14 минут
К сожалению на своём "старичке" файл Microsoft Access База данных (3).accdb посмотреть не смогу.

@snipe · 09.10.2014, 09:58

конвертировал в формат 2000
ниже не могу

mobile · 09.10.2014, 10:48

Сообщение от nevada174

В табл. "АРХИВ" поле [Номер п/п] не является счетчиком и не является ключевым

Смотрим в конструкторе. И счетчик, и ключ

@nevada174 · 09.10.2014, 11:26 **[ТС]**

mubile Да в БД Удалить в Архив.rar что выложил может быть [Номер п/п] ключевое поле. Эта БД не показатель языками цепляться - это вариант реализации перемещения строки из табл. "Главная" в табл. "АРХИВ". Что мешает убрать ключ??? В рабочем варианте БД таблица "АРХИВ" ключей не имеет вообще!!! Но я здесь не затем чтобы блестать остроумием.

snipe За пример СПАСИБО!!!
Практическим ничем не рознится с моими "экспериментами"), но всё это как я и представлял себе приводит к выводу: Проще сваять новую БД. Но таковой команды не было, поэтому буду "допиливать" и "докручивать" что имею.

Ещё раз спасибо всем за оказанную помощь и содействие в реализации вопроса!

@alvk · 15.10.2014, 03:33

Сообщение от nevada174

[Номер п/п] ключевое поле

Ключевым то он будет, но порядковым никогда.

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@snipe 4089 / 1469 / 401 Регистрация: 07.08.2013 Сообщений: 3,672
	08.10.2014, 13:56
	капризы у вас не правильные зачем вторая табла если можно просто добавить поле Логическое в основной таблице и ставить галки архивная запись или нет а то началось - гонять записи из одной таблы в другую не хотите Логическое поле поставьте поле типа Дата и ставьте дату когда определились архивная запись или нет 1

@nevada174 0 / 0 / 0 Регистрация: 05.10.2014 Сообщений: 14
	08.10.2014, 14:21 [ТС]
	Спасибо отозвавшимся форумчанам! В применении Логического поля в таб. "Главная" не совсем приятная вещь в плане того, что при экспорте таб. "Главная" в Excel ставшими (на момент экспорта таблицы) не нужными записи на ряду с нужными экспортируются, что не облегчает дальнейшую обработку информации непосредственно в Excel. Но и удалять безвозвратно данные тоже не есть хорошо. Как обычно бывает, сегодня инфа не нужна, а через пол года появляется необходимость в их восстановлении. Вот и приходится перегонять из одной табл. в другую. 0

@boby104 1267 / 449 / 129 Регистрация: 21.03.2013 Сообщений: 1,210
	08.10.2014, 15:12
	Согласен с мобайлом Перегонять данные в другую (архивную) таблицу имеет смысл, когда нужно фиксировать все изменения записи в разрезе дат и пользователей у вас это пока не предусмотрено. поэтому поля достаточно ... не хотите логического добавьте текстовое - это поможет ранжировать записи по их статусу например Новая, Включена в обработку, Утверждена, Требует подтвержения и Удалена 1

@nevada174 0 / 0 / 0 Регистрация: 05.10.2014 Сообщений: 14
	08.10.2014, 16:57 [ТС]
	Всем спасибо! Поэксперементирую с полем по советам mobile и boby104 0

mobile 26827 / 14507 / 3192 Регистрация: 28.04.2012 Сообщений: 15,782
	09.10.2014, 00:28
	Ну, что ж, раз Вы избирательно слушаете рекомендации, то вот Вам вариант для эксперимента: 1. В форме удалите запись с максимальным номером - Суслопаров Алексей Викторович с номером 6. 2. Сожмите базу данных. Это нормальный рабочий прием для сборки мусора 3. Снова зайдите в БД и занесите в таблицу другого человека или нескольких 4. Опять удалите запись с номером 6 Теперь Вы ожидаете что в архиве будет 2 записи. Зайдите и посмотрите 1

@snipe
	09.10.2014, 06:22
	Не по теме: Шарик: Я за ним полдня бегал что бы фотографию сделать Матроскин: Погоди, ты еще за ним полдня бегать будешь Шарик: это еще почему же? Матроскин: Что бы фотографию отдать (м/ф Каникулы в Простоквашино) nevada174, вот у вас сейчас стоит задача поместить записи в архив и как вы изначально хотели это делать - перемещением в другую таблицу(о всех "прелестях" такого действа на пальцах объяснил mobile) но на практике возникнет обратная задача вернуть из архива записи - хотел бы я посмотреть как вы ее решите. Принцип - на зло мужу сяду в лужу в данной ситуации не подходит вам предлагают решение из серии дешево и сердито (максимально эффективное при минимуме затрат) Более чем уверен что база ваша не такая громоздкая как Вам кажется на первый взгляд, я к тому что предлагаемое всеми решение для Вашей базы оптимальное а именно поставить индикатор того что запись архивная - это может быть что угодно Логическое поле которое просто показывает что запись в архиве, поле типа дата - если поле пустое то запись не в архиве если с датой то можно узнать когда поместили, текстовое поле - резолюция при внесении записи в архив или кто из юзеров поместил запись в архив можно несколько полей в которые поместится инфа об архивации записи еще варианты можно сделать таблицу в которой указывать id записей которые помещены в архив с заполнением дополнительной информации в конце концов можно заморочиться с репликацией как видите вариантов много и поверьте есть еще но среди этих вариантов не будет такого что бы перегонять записи из одной таблицы в другую - слишком это трудозатратно есть еще одна хитрость - то что видит юзер и то что есть на самом деле - может быть не одно и тоже например юзер нажимает кнопку удалить запись и все - больше он ее не видит, искренне считая что стер информацию, а на самом деле просто поставил галочку что бы информация не показывалась или контрол комбобокс - юзер видит список, который проггер определил что он будет отображаться, а в таблицу попадают данные присоединенного столбца в котором может быть совершенно другая информация. 0

@nevada174 0 / 0 / 0 Регистрация: 05.10.2014 Сообщений: 14
	09.10.2014, 09:41 [ТС]
	Именно так! БД создана в ДевяностоЛохматом году. Добавлено через 14 минут К сожалению на своём "старичке" файл Microsoft Access База данных (3).accdb посмотреть не смогу. 0

@nevada174 0 / 0 / 0 Регистрация: 05.10.2014 Сообщений: 14
	09.10.2014, 11:26 [ТС]
	mubile Да в БД Удалить в Архив.rar что выложил может быть [Номер п/п] ключевое поле. Эта БД не показатель языками цепляться - это вариант реализации перемещения строки из табл. "Главная" в табл. "АРХИВ". Что мешает убрать ключ??? В рабочем варианте БД таблица "АРХИВ" ключей не имеет вообще!!! Но я здесь не затем чтобы блестать остроумием. snipe За пример СПАСИБО!!! Практическим ничем не рознится с моими "экспериментами"), но всё это как я и представлял себе приводит к выводу: Проще сваять новую БД. Но таковой команды не было, поэтому буду "допиливать" и "докручивать" что имею. Ещё раз спасибо всем за оказанную помощь и содействие в реализации вопроса! 0