|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
И снова, здравствуйте. При переводе системы с mdb+mdb на mdb+SQL возникла очередная проблема, вызванная различным поведением Access и SQL server. Заключается она в следующем: при обновлении поля таблицы данными из присоединённой таблицы, в случае, когда на каждую строку исходной таблицы приходится несколько строк присоединённой, результат для Access получается как суммарное/последовательное обновление каждой из соотнессёных строк. А результат SQL Server (как и написано в его документации) недетерминированное обновление какой нибудь из соотнесённых строк. В Access: Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Получается: id valB1 62 33 0 На SQL server: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Получается: id valB1 12 13 0 Исправить проблему для одного простого запроса можно группировкой: Код: sql 1.
Но, таких запросов много и они, в основном, не простые. Писать программу по исправлению текста запросов не просто. Но есть ли другие варианты? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2018, 14:03 |
|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
4d_monster, Во втором случае получается что в В добавились только первые из А... Может изменить формирование А: - первый раз insert (для нового id) - далее update (старое значение + новое) Тогда и второй этап не нужен (в А будет то, что должно было быть в В) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2018, 15:43 |
|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
4d_monster, дикие запросы какие-то. Перепишите лучше их. Как вы к ним вообще пришли? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2018, 15:48 |
|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
vmag, Insertы тут для наполнения тестовых таблиц. По факту есть "целевая" таблица в которой данные обновляются данными из другой таблицы. Проблема возникает когда одной строке целевой таблицы соответствует несколько чужих строк. Аксес обновляет целевую строку каждой чужой, а SQL server обновляет целевую строку одной случайной чужой строкой. P.S.: В базе есть UPDATEы в которых присутствуют JOINы 3 - 5 таблиц. И целевая таблица в середине цепочки этих JOINов, поэтому просто обернуть в суммирующий группирующий подзапрос не получается. Хотя 90% запросов подходят для "оборачивания" Запросов с UPDATEприблизительно5 таблиц14 таблицы 293 таблицы 1282 таблицы 5721 таблица 685всего1415 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2018, 16:02 |
|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
Озверин, Легаси код, накопленный за 20 лет. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2018, 16:04 |
|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
Нашёл еще такой запрос: Код: sql 1.
Т.е. Аксесс в B.valB впишет количество соединённых строк из A. Ну а SQL Server просто 1. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2018, 08:35 |
|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
4d_monsterНашёл еще такой запрос: Код: sql 1.
Т.е. Аксесс в B.valB впишет количество соединённых строк из A. Ну а SQL Server просто 1. потому что логики в запросах нет при такой структуре. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2018, 09:16 |
|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
Озверинпотому что логики в запросах нет при такой структуре. Я это знаю. Я, ещё до осознания проблемы с UPDATE, один запрос такого типа для ускорения переписал в аксессе и при пререписывании пользовался логикой SQL Server, естественно получил везде 1, что прокатило на тестовых данных, но было обнаружено на реальных. И хочу понять как это исправить, какие есть варианты, кроме ручного переписывания ? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2018, 09:28 |
|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
4d_monsterОзверинпотому что логики в запросах нет при такой структуре. Я это знаю. Я, ещё до осознания проблемы с UPDATE, один запрос такого типа для ускорения переписал в аксессе и при пререписывании пользовался логикой SQL Server, естественно получил везде 1, что прокатило на тестовых данных, но было обнаружено на реальных. И хочу понять как это исправить, какие есть варианты, кроме ручного переписывания ? я вас настоятельно советую переписать, потому что найденный костыль может только усугубить ситуацию. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2018, 09:43 |
|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
4d_monsterИсправить проблему для одного простого запроса можно группировкой: Код: sql 1.
А вы тестировали этот запрос? ИМХО, если в источнике используется не обновляемый запрос, то вся конструкция будет не обновляемой. А с DSum() прокатит. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2018, 11:53 |
|
привести поведение UPDATE на SQL Server к поведению как у Access
|
|||
---|---|---|---|
#18+
Кривцов Анатолий4d_monsterИсправить проблему для одного простого запроса можно группировкой: Код: sql 1.
А вы тестировали этот запрос? ИМХО, если в источнике используется не обновляемый запрос, то вся конструкция будет не обновляемой. А с DSum() прокатит. Я это на сервере тестировал, там можно обновлять без Dsum. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2018, 13:07 |
|
|
start [/forum/topic.php?fid=45&msg=39726986&tid=1611063]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
255ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
others: | 19ms |
total: | 380ms |
0 / 0 |