Запрос ссылок Другой - доступ к SQL Server

Question

Доброе утро,

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

Мы разрабатываем Microsoft Access для подключения к базе данных SQL Server через соединение ODBC.

Мне дали невероятно большой сквозной SQL-запрос, больший, чем он может быть обработан в MS Access. В этом сквозном запросе есть метод в методе WITH...AS.

Я надеюсь, что смогу разделить этот, особенно большой, SQL-запрос на два: Query One (подзапрос) и Query Two (который ссылается на результаты подзапроса)

Я знаю, что используя общие запросы Access, я могу написать макрос следующим образом...

Sub myQuery()
' Edited from http://www.dbforums.com/showthread.php?1667831-Run-multiple-queries-in-sequence-on-click

' On Error GoTo ErrHandler

' Run the first query
MsgBox "Starting first query"
DoCmd.OpenQuery "first_Query"
DoEvents

' Run the second query
MsgBox "Done. Now starting second query"
DoCmd.OpenQuery "second_Query"
DoEvents

MsgBox "Done!"
End Sub

Однако это должны быть сквозные запросы. Я считаю, что огромная строка SQL создается с помощью ряда пользовательских данных. Несмотря на это, у меня нет возможности изменить сквозной SQL, который мне дали.

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

Вот пример того, с чем я работаю...

WITH queryOne AS
    (
        SELECT fooID
        FROM tblFoo
        WHERE foodate > ...
    )

SELECT foo, fooone, footwo, foothree
FROM tblOtherFoo
WHERE fooID = OtherFooID

Тем не менее, запрос составляет 50000+ символов, что превышает ограничение ~37 КБ.

Пожалуйста, не стесняйтесь задавать любые вопросы. Я озадачен этим и был бы признателен за любые отзывы или альтернативные ресурсы.

Спасибо!

Answer 1

Непонятно, что вы подразумеваете под тем, что ссылается на первое или предыдущее? Зачем ломать что-то, что вам дали, что должно работать нормально? Так что просто поместите тот существующий t-sql, который вам дали, в процедуру процедуры магазина. В T-SQL вы можете легко заставить некоторый SQL работать с некоторым предыдущим SQL, но зачем разбивать такое ОГРОМНОЕ огромное количество кода и вносить ошибки? Вам потребуются ГОДЫ И ГОДЫ, чтобы разбить ИЗВЕСТНЫЙ работающий огромный T-SQL, который был построен и разработан для вас. (То, что долго, вероятно, заняло несколько лет и команда разработчиков, чтобы создать). По самым скромным подсчетам, такая рутина стоила бы 50 000 долларов или даже 100 000 долларов на разработку.

Несомненно, что рабочий t-sql, который вам дали, может ссылаться на предыдущие данные или даже выбирать в таблицы #Temp, с которыми может работать дополнительный t-sql.

Если у вас уже есть рабочий код и запрос?

Просто возьмите этот запрос T-SQL и просто вставьте его в процесс магазина. Вы будете делать это на сервере SQL и даже не трогать или беспокоиться о доступе.

Поэтому не создавайте какой-либо макрос в Access, который вызывает несколько отдельных запросов, но поместите все t-sql в процедуру хранилища SQL и просто вызовите этот огромный беспорядок один раз из Access.

Возможно, что заданный вами t-sql неверен, но если предположить, что t-sql верен, просто поместите весь этот длинный беспорядок в рабочий процесс хранилища. Вы не помещаете этот SQL в Access, и вам не нужно, чтобы этот беспорядок внутри Access.

Так что пусть t-sql работает на сервере sql - не беспокойтесь о Access, пока этот длинный запрос не работает на сервере sql. ТОЛЬКО ПОТОМ вы запускаете Access.

Таким образом, вы затем создаете простой запрос PT в Access, который вызывает огромный длинный T-SQL беспорядок, который вам дали. Но этот "беспорядок" должен быть размещен на сервере SQL, а не в Access.

Поэтому создайте PT-запрос в Access, который вызывает ваш "предполагаемый" рабочий t-sql, который вам дали. SQL, который вы сохраните в запросе Access PT, будет таким

Exec my_StupidLongSQLProc

Сохраните вышеупомянутое как запрос PT. Тогда в коде VBA идут:

Currentdb.QueryDefs("MyPTQuery").Execute

Если вам нужно передать некоторые значения из Access, перейдите:

With CurrentDb.QueryDefs("MyPTQuery")
   .sql = "exec My_StupidLongSQLproc " & p1 & "," p2
   .Execute
End with

Выше мы передаем два значения VBA из Access в большой беспорядок в SQL, который у вас есть - процедура хранилища, приведенная выше, является просто примером доступа к двум параметрам, переданным из Access VBA. Если заданный вами t-sql не требует значений из Access, то первый единственный.execute выполнит эту работу.

И если вы ДЕЙСТВИТЕЛЬНО получили такую ​​длинную подпрограмму, которая является правильной t-sql, то она, вероятно, уже имеет параметры в рабочем t-sql (и опять же, вы не хотите связываться или изменять такой огромный длинный рабочий t-sql что тебе подарили).

Таким образом, вам нужна только одна строка кода в Access, и ваш существующий длинный t-sql, который вам дали при правильном написании, может быть помещен в процедуру хранилища (при условии, что вы действительно получили правильно работающий PT-запрос).

Поэтому, если вы ДЕЙСТВИТЕЛЬНО получили огромный массивный рабочий оператор t-sql, просто поместите этот T-sql и РАБОТАЮЩИЙ t-sql на SQL-сервер как процесс и вызовите его с одной строкой кода, как указано выше.

Поэтому попытка отделить это от Access приведет только к серверу, который вызовет бедность во всем мире, и ЛЮБОЙ крошечный шаг промахов или разрыв этой огромной рутины приведет к бедности во всем мире и голоду у детей, когда вы попытаетесь "починить" эту замечательную работу. -Sql, что вам дали. Как уже отмечалось, что-то, что долго создавалось, заняло бы у разработчиков огромные ресурсы. Если вы прикоснетесь к одной строке кода или разберетесь с ней, а затем испортите ее, вам понадобится команда разработчиков, которая потратит несколько месяцев, чтобы исправить то, что вы сломали.

Таким образом, МОМЕНТАЛЬНО, вы начинаете разбивать такой огромный длинный беспорядок - это момент, когда вы проиграли эту битву, и потратите несколько лет своей жизни, пытаясь исправить этот сумасшедший длинный t-sql, который вам дали, который, как утверждают, уже является правильным рабочим кодом.