2017-01-28 3 views
0

Я пишу простой конфигуратор в MS Access. Существуют два типа правил: обязательный и недействительный. Для недействительных правил я использую этот SQL, и она отлично работает:Доступ к Ms: запрос DELETE с оператором JOIN и NOT EQUAL

DELETE DISTINCTROW RuntimeBOM.* 
FROM CurrentInvalid 
INNER JOIN RuntimeBOM ON ([RuntimeBOM].[OPTION] = [CurrentInvalid].[Invalid option]) 
AND ([RuntimeBOM].[FEATURE] = [CurrentInvalid].[Invalid feature]) 
WHERE RuntimeBOM.SessionID=fOSUserName(); 

Для обязательных правил я судимое это одно, но это не влияет на запись в таблице, на самом деле, она возвращает ошибку во время выполнения «3086» (это невозможно удалить из указанных таблиц):

DELETE DISTINCTROW RuntimeBOM.* 
FROM CurrentMandatory 
INNER JOIN RuntimeBOM ON (RuntimeBOM.FEATURE = CurrentMandatory.MandatoryFeature) 
AND (RuntimeBOM.OPTION <> CurrentMandatory.MandatoryOption) 
WHERE RuntimeBOM.SessionID=fOSUserName(); 

fOSUserName() является функцией VBA, чтобы получить имя пользователя компьютера, на котором выполняется приложение.

╔══════════════╗ ╔══════════════════════════════════════════╗ ╔════════════════════════════════════════════╗ 
║ RuntimeBOM ║ ║    CurrentInvalid    ║ ║    CurrentMandatory    ║ 
╟───────┬──────╢ ╟────┬──────┬───────────────┬──────────────╢ ╟────┬──────┬────────────────┬───────────────╢ 
║FEATURE│OPTION║ ║Feat│Option│Invalid feature│Invalid option║ ║Feat│Option│MandatoryFeature│MandatoryOption║ 
╠═══════╪══════╣ ╠════╪══════╪═══════════════╪══════════════╣ ╠════╪══════╪════════════════╪═══════════════╣ 
║FT001 │OP001 ║ ║FTaa│OPaa │FT001   │OP001   ║ ║FTaa│OPaa │FT002   │OP008   ║ 
║FT001 │OP002 ║ ║FTaa│OPaa │FT001   │OP002   ║ ╚════╧══════╧════════════════╧═══════════════╝ 
║FT001 │OP003 ║ ║FTaa│OPaa │FT001   │OP004   ║ 
║FT001 │OP004 ║ ║FTaa│OPaa │FT001   │OP005   ║ 
║FT001 │OP005 ║ ╚════╧══════╧═══════════════╧══════════════╝ 
║FT002 │OP006 ║ 
║FT002 │OP007 ║ 
║FT002 │OP008 ║ 
║FT002 │OP009 ║ 
║FT002 │OP010 ║ 
╚═══════╧══════╝ 

В этом случае представьте, пользователь выбрал «FTAA» и «OPaa» где-то, и по этой причине «CurreintINvalid» и «CurrentMandatory» заполняются таким образом. SQL для недействительных правил удаляет записи внутри RuntimeBOM, где FEATURE равно FT001, а OPTION - «OP001», «OP002», «OP004», «OP005» (как определено в «CurrentInvalid»). SQL для обязательных правил удаляет все записи внутри RuntimeBOM, где FEATURE равно FT002, а OPTION не равно «OP008» (как определено в «CurrentMandatory»). Ожидаемые результаты:

╔══════════════╗ 
    ║ RuntimeBOM ║ 
    ╟───────┬──────╢ 
    ║FEATURE│OPTION║ 
    ╠═══════╪══════╣ 
    ║FT001 │OP003 ║ 
    ║FT002 │OP008 ║ 
    ╚═══════╧══════╝ 

Thank you!

+0

Проверьте версию 'SELECT' проблемы' DELETE'. Является ли он доступным для обновления запросом? Связаны ли эти таблицы или запросы, в частности * CurrentMandatory *? – Parfait

+0

Спасибо за ваш ответ. Это стол, странно, что первое удаление отлично работает. а второй нет. если преобразовать второй запрос в SELECT, он работает. – Axel

ответ

0

Либо вы пытаетесь удалить запись, которая не является уникальной, и/или одно из ваших объединений - это объединение данных.

Задать вопрос как Выберите запрос и подтвердите свои результаты.

+0

Спасибо за ваш ответ, я отлаживал от версии SELECT версии запроса. Это было очень полезно. – Axel

0

ОК, благодаря предложениям, я думаю, что нашел решение. Кажется, что первый «DELETE» работает отлично, потому что внутри оператора «JOIN» есть только «=» сравнения. во втором SQL я оставил «=» заявление внутри «JOIN», в то время как я переехал «<>» заявление внутри «ГДЕ»:

DELETE DISTINCTROW RuntimeBOM.* 
FROM CurrentMandatory INNER JOIN RuntimeBOM ON (RuntimeBOM.FEATURE)=[CurrentMandatory].[MandatoryFeature] 
WHERE RuntimeBOM.SessionID=fOSUserName() And ((RuntimeBOM.OPTION)<>CurrentMandatory.MandatoryOption); 

Спасибо.

Смежные вопросы