На самом деле, самый быстрый подход?
Ну, это тот, который кажется ОЧЕНЬ противоречивым, и я мог бы ОЧЕНЬ долго объяснять, почему. Однако, попробуйте это, вы обнаружите, что он работает в 10 раз или лучше, чем у вас сейчас. Фактически, это может быть ближе к 100x, чем у вас.
Мы будем предполагать, что у нас есть стандартная связанная история к dbo.Client_Data
. Скорее всего, ссылка Client_Data
, или даже dbo_Cliet_Data
.
Итак, используйте это:
Dim rs As DAO.Recordset
Dim rsIns As DAO.Recordset
If Me.Dirty = True Then Me.Dirty = False ' write any pending data
Set rsIns = CurrentDb.OpenRecordset("dbo_Client_Data", dbOpenDynaset, dbSeeChanges)
Set rs = Me.RecordsetClone
rs.MoveFirst
Do While Not rs.EOF
With rsIns
.AddNew
!ClientID = rs!ClientID
!Note = Me.Txt_Note
!Value_1 = Me.Txt_Value1
!Value_2 = Me.Txt_Value2
.Update
End With
rs.MoveNext
Loop
rsIns.Close
MsgBox "All Client Added!", , "Add client"
Обратите внимание на количество бонусов выше. Наш код чистый - нам НЕ нужно беспокоиться о типах данных, таких как даты, или о проблеме из-за вашей грязной цитаты. Если бы даты были включены, мы снова могли бы просто назначить, не беспокоясь о разделителях. Мы также получаем бонус защиты от инъекций при загрузке!
Мы также использовали me.RecordSetClone
. Это не обязательно делать. Это поможет повысить производительность, но наиболее значительным является то, что при перемещении указателя записи позиция записи формы не пытается следовать. это избавит от большого количества мерцания. Это также может устранить ОГРОМНЫЕ проблемы, если в этой форме существует текущее событие.
Так что, хотя ОЧЕНЬ хорошая идея (recordsetclone), она не является главной причиной значительного увеличения производительности, которое вы увидите здесь. RecordSetClone
- это то же самое, что и me.RecordSet
, но вы можете "перемещать" и проходить через набор записей без указания главной формы.
Так что, действительно, самый "базовый" подход кода и тот, который будетработа скажем, доступ без SQL Server оказывается лучшим подходом. Это меньше кода, меньше грязного кода, и избавит вас от всех хлопот, чтобы настроить + построить хранимую процедуру SQL Server. Все ваши концепции были не нужны, и хуже всего они повлекут за собой снижение производительности. Попробуйте приведенную выше концепцию.
Access будет объединять и управлять несколькими вставками за один раз. Концепция и идея о том, что всегда использовать команды обновления / вставки SQL по сравнению с reocrdsets, является ДЕЙСТВИТЕЛЬНО ОГРОМНЫМ городским мифом, к которому стремятся многие разработчики доступа. Это не верно. В действительности проблема заключается в том, что если вы можете заменить цикл VBA огромного числа, скажем, отдельных выполненных обновлений, на ОДИН единый оператор обновления SQL, тогда да, вы на много километров вперед (чтобы использовать одно обновление SQL поверх некоторого цикла VBA).
Однако, если вам нужно выполнить несколько операций, и каждая операция находится в одной строке? Вместо «множества отдельных» обновлений SQL, а в этом случае (будучи) в подавляющем большинстве случаев, набор записей будет вращаться вокруг целого ряда отдельных команд обновления / вставки для достижения той же цели. Это даже близко, и вы получите в 10, если не в 100 раз лучшую производительность, используя вышеуказанные концепции.