Здравствуйте, Ramzes14, Вы писали:

R>Здравствуйте, GuinPin

R>Я пишу на VB 6.

R>Если я правильно понял то ты и справочники и документы
R>хочеш хранить в одном классе
R>если так то тода не пойдет.

R>Это как говорится мухи отдельно г.. отдельно
R>я строю отдельно класс документа
R>который отвечает за обновление,извлечение,вставку и удаление данных из БД

Ну а смысл?
На данный момент у меня не реализована работа с табличными частями документов, поэтому этот вопрос я пока оставлю в сторонке.
А теперь посмотри чем отличается справочник от документа _без_ табличной части (РКО, ПКО, Платежка и т.п.)... Правильно. Ничем
Ты в классе документа создаешь атрибуты, чоответствующие полям в БД, а я храню данные в хеш-массиве. И на верхнем уровне логика работы абсолютно одинакова:
Взять метаданные, построить запрос, получить данные, для агрегатных данных создать объекты, разложить все в массив.

На втором уровне уже идет разделение подкласс документов, подкласс справочников и подкласс периодики
Документы имеют свой набор обязательных полей и методы для загрузки табличных частей
Справочники свой набор обязательных полей
Периодика вообще конечный класс

На третьем уровне я реализую уже непосредственно документы и справочники добавляя необходимые поля и логику.

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

Me.Field("NomDoc")=55

вместо

Me.NomDoc=55

Но меня такой вариант не напрягает.

Здравствуйте, GuinPin, Вы писали:
Это и есть ADO и DAO