К примеру есть функция:

Function Identity() As Long
Dim Rst As Recordset
Set Rst = Application.CurrentProject.Connection.Execute("Select @@Identity as N")
Identity = Rst!N
Rst.Close
Set Rst = Nothing
End Function

Нужен ли оператор Set Rst = Nothing. Он что-то еще делает кроме присвоения пустого указателя? Если нет - то оператор лишний. Все равно к переменой после выхода из функции нет доступа.

Да, Павел, я согласен обьект тяжелый - из-за одной переменной целый Recordset.
Но как по другому написать не знаю. Придерживаюсь мнения что чем короче программа тем лучше, ну кроме конечно исключений.

Сначала на счет оптимизации.
У нас с Вами могут быть разные критерии. Я придерживаюсь критерия что большинство рутинной работы должен делать компютер, в том числе и при написании програм. Для меня програмирование сначала часть бизнеса а потом искуство.
С точки зрения бизнеса надо написать в кратчайший срок действуюшее приложение, с точки зрения искуства - что на это все и еще было приятно посмотреть. Поэтому я редко переписываю то что работает, но писать всегда надо лучше чем вчера.
Обьект Command посмотрел, чесно говоря он мне не понравился. Уж слишком много подготовительной работы. Функция которую я написал в примере немного простовата для обсуждения - один параметр. А если три параметра? Не кажется Вам что немного сложновато указывать, что возвращаемый параметр - это строка, и что ее длина столько то символов, и что в конце-концов это еще и возвращаемый параметр. В добавку этот параметр надо еще к списку приклеить. Что-то уж больно старыми временами попахивает, когда "тупой" машине все надо было разжовывать до последнего байта (тем более что эта информация уже есть на сервере!). А зачем тогда SQL - что б упростить работу с наборами данных, а зачем ADO - что б ее (работу) вернуть обратно что ли к ручной манипуляции данными.

...берусь утверждать, что запрашивать @@Identity с сервера незачем.
Как выяснилось действительно незачем. Написал функцию на этапе перехода от БД Accessa до SQL, когда изучал тригеры. Документация (Help) в Accessе по отношению к adp прямо таки никудышняя. Тут то выяснилось что тригеры вещь хорошая но со стандартными средствами не работают. Открываем таблицу, редагируем запись - и какая то страная ошибка, типа указатель на запись неверный или что-то еще, уже к счастью не помню. И вообще не понимаю, почему например в окне Access не сделать вьюшку тригеров, или хотя бы пометить таблицы в которых есть тригеры.

Павел. Разрешите Вас поблагодорить за конструктивный диалог.
Вот проблема с которой я когда-то столкнулся

CREATE TABLE [dbo].[TABLE1]
([ID] [int] IDENTITY (1, 1) NOT NULL ,
[Value] [int] NULL) ON [PRIMARY]
GO
CREATE TABLE [dbo].[TABLE2] ([ID] [int] IDENTITY (10, 1) NOT NULL ,
[Value] [int] NULL) ON [PRIMARY]
GO
ALTER TABLE [dbo].[TABLE1] WITH NOCHECK ADD
CONSTRAINT [PK_TABLE1] PRIMARY KEY NONCLUSTERED
([ID]) ON [PRIMARY]
GO
ALTER TABLE [dbo].[TABLE2] WITH NOCHECK ADD
CONSTRAINT [PK_TABLE2] PRIMARY KEY NONCLUSTERED
([ID]) ON [PRIMARY]
GO
Create Trigger TABLE1_Insert
On dbo.TABLE1
For Insert
As
Insert Table2 (Value) SELECT Value FROM Inserted
GO

Открываем таблицу 1 чтобы ввести данные и получаем сообщение об ошибке.
Думая не я один наступил на эти "грабли". Войдите в положение человека ничего незнающего о @@Identity и
о механизме работы Access и что таблицы и триггер был явно посложнее чем в примере.

>Триггеры, например, спокойно создаются, редактируются и удаляются прямо из окна А2K. - Согласен. Но если в базе много таблиц (к тому же они могут быть созданы разными пользователями), память у нас тоже не идеальная, то чтоб посмотреть какие таблицы имеют триггеры надо их ручками перебрать. Немножко неудобновато.