Доступ к SQL-копии

Question

У нас есть БД доступа, которая имеет набор локальных таблиц и форм ввода и т. Д., В которых пользователь сохраняет свои данные.

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

Каков наилучший способ разрешить пользователю изменять его изменения в SQL db, сохраняя локальную рабочую копию, чтобы он мог работать в автономном режиме, а затем выталкивать файлы, когда он доволен новой версией данных?

Моя первая мысль заключалась в добавлении таблиц SQL в виде связанных таблиц, которые я мог бы затем обрезать (доступ делает это) или удалить содержимое в каждой таблице, а затем сделать вставку для каждой таблицы.

Могу ли я вызвать SP от доступа на SQL усечение таблицы, как я есть проблема бегущий удаляет

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

Спасибо за вашу помощь

Answer 1

Вы должны быть в состоянии использовать объект ADODB.Command для выполнения хранимых процедур.

EDIT:

Этот пример копируется из Using ADO in VB and Access

Sub ADO_COMMAND_CONNECTION_TEST() 
Dim cmd As New ADODB.Command 
Dim rs As ADODB.Recordset 
Dim strConn As String 

    cmd.ActiveConnection = " DRIVER={SQL Server};" & _ 
     "Server=UKDUDE;DATABASE=pubs;UID=sa;PWD=;" 
    cmd.CommandText = "byroyalty" 
    cmd.CommandType = adCmdStoredProc 
    cmd.Parameters.Refresh 
    cmd.Parameters(1).Value = 25 

    Set rs = cmd.Execute 

' Recordset now has authors with 25% royalty..... 

End Sub 

Answer 2

Никогда не использовать MS Access связанные таблицы с MS SQL.

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

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

Если вы хотите, чтобы пользовательские действия записывались напрямую, то ADP, безусловно, лучший метод.

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

Answer 3

Я не понимаю, почему вы просто не связываетесь напрямую с данными SQL Server и используете его напрямую, вместо того, чтобы беспокоиться о сохранении второй копии. Это стандартный способ доступа к действию - почему вы сопротивляетесь естественным возможностям используемого инструмента?