Блог

#database-design #ms-access #ms-access-2007

#проектирование базы данных #ms-access #ms-access-2007

Вопрос:

Комментарии:

1. Насколько велик внутренний файл данных? Если это меньше 1 ГБ, я бы предположил, что у вас нет никаких причин для архивирования. Если это происходит медленно, то вам, вероятно, нужно сделать две вещи, настроить регулярное обслуживание (чтобы оно регулярно уплотнялось) и внедрить надлежащую индексацию.

2. (a) К сожалению, я не могу запустить регулярное обслуживание. (b) На основе разговоров с посредниками ни посредники, ни обычные пользователи не могут устранить даже самые элементарные проблемы (например, исправить опечатку в форме). (c) Несколько лет назад я действительно столкнулся с огромными повторяющимися проблемами с Access ‘ compact и repair. (d) Объем серверной части приближается к 1 ГБ. Соедините все это вместе, и я действительно не решаюсь пытаться реализовать какой-либо тип регулярного обслуживания.

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

4. Что касается реализации правильной индексации — я проводил рефакторинг по ходу работы. К сожалению, для исправления нескольких ключевых областей потребуется больше времени, чем выделит клиент.

5. Короче говоря, я бы сказал, что вашим клиентам нужен момент осознания Иисуса, когда вы разъясняете им тот факт, что они не действуют так, как будто их данные вообще имеют какую-либо ценность. Это не имеет никакого отношения к проблеме архивирования — если они не выполняют регулярное обслуживание серверной части и не создают регулярные резервные копии, они облажаются, если что-то пойдет не так. Увеличение размера до SQL Server на самом деле не исправит это, если они не будут осуществлять регулярное обслуживание и резервное копирование на своем SQL Server. Конечно, требуемые административные операции на серверной части Jet / ACE так же поддаются написанию сценариев, как и на SQL Server…

Ответ №1:

 Public Sub DoArchive()
    Const cstrArchive As String = "C:dbarchive.mdb"
    Dim db As DAO.Database
    Dim tdf As DAO.TableDef
    Dim strAppend As String
    Dim strCutoff As String
    Dim strDelete As String
    Dim strWhere As String
    Dim strMsg As String

On Error GoTo ErrorHandler

    Set db = CurrentDb
    strCutoff = "#" amp; Year(Date) - 1 amp; "/01/01#"
    strWhere = " WHERE date_field < " amp; strCutoff
    For Each tdf In db.TableDefs
        If Len(tdf.Connect) > 0 Then
            strAppend = "INSERT INTO [" amp; tdf.name amp; "] IN '" amp; _
                cstrArchive amp; "' SELECT * FROM [" amp; tdf.name amp; _
                "]" amp; strWhere amp; ";"
            Debug.Print strAppend
            ''CurrentDb.Execute strAppend, dbFailOnError
            strDelete = "DELETE FROM [" amp; tdf.name amp; "]" amp; _
                strWhere amp; ";"
            Debug.Print strDelete
            ''CurrentDb.Execute strDelete, dbFailOnError
        End If
    Next tdf

ExitHere:
    On Error GoTo 0
    Set tdf = Nothing
    Set db = Nothing
    Exit Sub

ErrorHandler:
    strMsg = "Error " amp; Err.Number amp; " (" amp; Err.description _
        amp; ") in procedure DoArchive"
    MsgBox strMsg
    GoTo ExitHere
End Sub
  

Комментарии:

1. @HansUp — спасибо, что дал мне надежду, что я не сумасшедший. Предположения 1, 2 и 3 — да

2. Предположение 4 — Я желаю! В основном, они подразделяются на четыре типа: поле FY (текст), поле date (дата / время), простые таблицы поиска, которые не сильно изменятся, сложные таблицы поиска, которые изменят существующие записи, но не будут иметь управления версиями. Я вернусь к этому. Предположение 5 — В основном да. Это база данных, которая передается от одного плохого программиста другому всякий раз, когда становится очевидным достаточно проблем. Поэтому я не хочу создавать помехи следующему плохому sap путем удаления или изменения первичных ключей.

3. Хорошо! Да, я подумал, что предположение № 4 может оказаться реальной проблемой… но не для меня, потому что я упростил это для себя. 🙂 Удачи с этим.

4. В этом случае я предложу таблицу имен ссылок, которая включает еще один столбец для указания порядка, в котором они должны быть обработаны. Затем, вместо перебора TableDefs, используйте набор записей, основанный на этой новой таблице, для запуска процедуры. Я предполагаю, что проблема с упорядочением связана с удалениями из исходного MDB; Я не понимаю, зачем вам вообще нужны взаимосвязи в архивном MDB. Другим подходом было бы удалить связи перед вашей операцией архивирования, а затем повторно создать их после. Это могло бы сработать, но думаю, я бы предпочел для этого отдельную таблицу.

5. Я бы снова проголосовал за отсутствие архивирования. Я бы также отметил, что если вы удаляете большие пакеты записей для архивирования, вы теперь приводите свою базу данных в состояние, которое гарантирует плохую производительность, если вы не создадите резервную копию и не запустите на ней compact. Это можно автоматизировать как часть процесса архивирования, но суть в том, что если вы можете сделать это здесь, вы можете сделать это как часть обычной процедуры автоматического обслуживания (VBScripts, запускаемых на файловом сервере планировщиком задач Windows, будет достаточно). Даже если вы выполняете архивирование, вам действительно необходимо выполнять регулярное обслуживание и резервное копирование.