Медленный код SQL на локальном сервере в MS Access

Question

У меня есть конкретный оператор SQL, который занимает около 30 секунд, и мне интересно, может ли кто-нибудь увидеть проблему с ним или где мне нужна дополнительная индексация.

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

Благодаря

PG

SELECT TabDrawer.DrawerName, TabDrawer.DrawerSortCode, TabDrawer.DrawerAccountNo, TabDrawer.DrawerPostCode, QryAllTransactons.TPCChequeNumber, tabdrawer.drawerref 
FROM TabDrawer LEFT JOIN QryAllTransactons ON TabDrawer.DrawerRef=QryAllTransactons.tpcdrawer 
WHERE (Forms!FrmSearchCompany!SearchName Is Null 
     Or [drawername] Like Forms!FrmSearchCompany!SearchName & "*") 
     And (Forms!FrmSearchCompany.SearchPostcode Is Null 
     Or [Drawerpostcode] Like Forms!FrmSearchCompany!Searchpostcode & "*") 
     And (Forms!FrmSearchCompany!SearchSortCode Is Null 
     Or [drawersortcode] Like Forms!FrmSearchCompany!Searchsortcode & "*") 
     And (Forms!FrmSearchCompany!Searchaccount Is Null 
     Or [draweraccountno] Like Forms!FrmSearchCompany!Searchaccount & "*") 
     And (Forms!FrmSearchCompany!Searchcheque Is Null 
     Or [tpcchequenumber] Like Forms!FrmSearchCompany!Searchcheque & "*"); 
    "); 

---

EDIT

Захват вверх, кажется, в который формирует запрос QryAllTransactons.

SELECT 
    "TPC" AS Type, 
    TabTPC.TPCRef, 
    TabTPC.TPCBranch, 
    TabTPC.TPCDate, 
    TabTPC.TPCChequeNumber, 
    TabTPC.TPCChequeValue, 
    TabTPC.TPCFee, 
    TabTPC.TPCAction, 
    TabTPC.TPCMember, 
    tabtpc.tpcdrawer, 
    TabTPC.TPCUser, 
    TabTPC.TPCDiscount, 
    tabcustomers.* 
FROM 
    TabTPC 
    INNER JOIN TabCustomers ON TabTPC.TPCMember = TabCustomers.CustomerID 

UNION ALL 

SELECT 
"CTP" AS Type, 
    TabCTP.CTPRef, 
    TabCTP.CTPBranch, 
    TabCTP.CTPDate, 
    TabCTP.CTPChequeNumb, 
    TabCTP.CTPAmount, 
    TabCTP.CTPFee, 
    TabCTP.CTPAction, 
    TabCTP.CTPMember, 
    0 as CTPXXX, 
    TabCTP.CTPUser, 
    TabCTP.CTPDiscount, 
    TABCUSTOMERS.* 
FROM 
    TabCTP 
    INNER JOIN TabCustomers ON Tabctp.ctpMember = TabCustomers.CustomerID; 

Я сделал справедливый бит работы с простыми профсоюзными запросов, но никогда не было этого раньше ...

Answer 1

Две вещи. Поскольку это база данных Access с бэкэнд SQL Server, вы можете добиться значительного улучшения скорости, переведя ее в сохраненный proc.

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

Answer 2

Сначала попробуйте уплотнении и ремонт файл .mdb.

Затем упростить ваш ИНЕКЕ:

WHERE 
    [drawername] Like Nz(Forms!FrmSearchCompany!SearchName, "") & "*" 
    And 
    [Drawerpostcode] Like Nz(Forms!FrmSearchCompany!Searchpostcode, "") & "*" 
    And 
    [drawersortcode] Like Nz(Forms!FrmSearchCompany!Searchsortcode, "") & "*" 
    And 
    [draweraccountno] Like Nz(Forms!FrmSearchCompany!Searchaccount, "") & "*" 
    And 
    [tpcchequenumber] Like Nz(Forms!FrmSearchCompany!Searchcheque, "") & "*" 

ли она по-прежнему работать медленно?

EDIT

Как оказалось, этот вопрос не ясно, что это до размера базы данных Access с SQL Server обратно конец и передний конец проекта Access.

Это проливает другой свет на всю проблему.

Можете ли вы подробнее объяснить , как весь этот запрос предназначен для использования?

Если вы используете его для заполнения RecordSource некоторой формы или отчета, я думаю, вы будете иметь возможность реорганизовать все это так:

• сделать вид на сервер SQL, который возвращает правильные данные
• запрос, вид с синтаксисом SQL сервера, а не с синтаксисом доступа
• позволить серверу разбирайтесь

Answer 3

Сколько строк в QryAllTransactons?

Если ваш результат возвращает 0 строк, то Access может сразу увидеть и остановить, но если он возвращает хотя бы одну строку, тогда ему нужно вытащить весь набор результатов QryAllTransactons, чтобы он мог выполнять соединение внутри. Это было бы моим первым предположением о том, что происходит.

Ваш лучший выбор, как правило, делать соединения на SQL Server.Попробуйте создать представление, которое делает LEFT OUTER JOIN, и запросить его.

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

Answer 4

Вы пытались запустить каждый из подзапросов в объединении? Обычно оптимизаторы не тратят много времени, пытаясь проверить эффективность между элементами объединения - каждый работает по существу.

Учитывая этот факт, вы также можете поместить логику «IF» в процедурный код и запустить каждый из тестов в некотором вероятном порядке обнаружения, без значительных дополнительных накладных расходов от большего количества вызовов.

Answer 5

Избавьтесь от подобных операторов.

В вашем случае они вам не нужны. Просто проверьте, если поле начинается с заданного значения, которое вы можете achive ти что-то вроде этого:

Left([field], Len(value)) = value 

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

SELECT 
    TabDrawer.DrawerName, 
    TabDrawer.DrawerSortCode, 
    TabDrawer.DrawerAccountNo, 
    TabDrawer.DrawerPostCode, 
    QryAllTransactons.TPCChequeNumber, 
    TabDrawer.DrawerRef 
FROM 
    TabDrawer 
    LEFT JOIN QryAllTransactons 
    ON TabDrawer.DrawerRef = QryAllTransactons.TpcDrawer 
WHERE 
    (Forms!FrmSearchCompany!SearchName Is Null 
    Or Left([drawername], Len(Forms!FrmSearchCompany!SearchName)) = Forms!FrmSearchCompany!SearchName) 
And 
    (Forms!FrmSearchCompany.SearchPostcode Is Null 
    Or Left([Drawerpostcode], Len(Forms!FrmSearchCompany!Searchpostcode)) = Forms!FrmSearchCompany!Searchpostcode) 
And 
    (Forms!FrmSearchCompany!SearchSortCode Is Null 
    Or Left([drawersortcode], Len(Forms!FrmSearchCompany!Searchsortcode)) = Forms!FrmSearchCompany!Searchsortcode) 
And 
    (Forms!FrmSearchCompany!Searchaccount Is Null 
    Or Left([draweraccountno], Len(Forms!FrmSearchCompany!Searchaccount)) = Forms!FrmSearchCompany!Searchaccount) 
And 
    (Forms!FrmSearchCompany!Searchcheque Is Null 
    Or Left([tpcchequenumber], Len(Forms!FrmSearchCompany!Searchcheque)) = Forms!FrmSearchCompany!Searchcheque) 

Обратите внимание, что вы сравниваете чувствительность к регистру. Я не совсем уверен, что подобный оператор в MS-Access нечувствителен к регистру. Преобразуйте обе строки в верхний или нижний регистр, если необходимо.

Answer 6

Когда вы перевернули, вы убедились, что таблицы были правильно проиндексированы? Индексы будут очень быстро исправлять запросы при правильном использовании (обратите внимание, что они также могут замедлять вставки/обновления/удаления, поэтому тщательно выбирайте, что индексировать)