Решил перевести технологию доступа к данным в моей программе с DAO на ADO. Связано это с размером дистрибутива, получающегося в итоге (дистрибутив проги на DAO весит значительно больше).
Так вот, в моей программе была реализована возможность создания определяемых пользователем полей. Юзеры сами могли создавать нужные им поля, по этим полям потом можно было делать выборку и они попадали в отчеты. Теперь, как я понимаю, создавать поле можно только при помощи синтаксиса DDL:
ALTER TABLE tblSomeTable ADD COLUMN SomeNewColumn TEXT(255) WITH COMP NOT NULL DEFAULT """""

Так вот вопрос, как мне задать AllowZeroLength to true
и задать свойство Caption для добавляемого поля? Можно ли это вообще сделать? В DAO все было очень просто.

Заранее большое спасибо.
Иван Абрамов, программист, CSBI.
http://adanalysis.narod.ru - моя программа для выбора автомобиля.

Спасибо, помогли.

Но, вообще говоря, я гляжу тут много чего подключать приходится.
Помимо самой библиотеки MS ActiveX Data Objects 2.5 Library я уже подключил msjro чтобы Compact делать. Надеюсь на ADOX дальнейшее подключение закончится.
А что без ADOX-а никак нельзя AllowZeroLength выставить (я имею в виду строкой sql)?

Возможно, я забыл сказать важное. Используется VB6 в качестве основного средства разработки программы. Compact надо делать программно из кода на VB6 в некоторых случаях (после удаления юзером большого количества записей, например, и пр.).

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

Пишу подробнее, хотя это конечно уже другая тема.
Дело в том, что мой 7-ми летний опыт программирования реляционных баз данных говорит о том, хранить определения добавленных пользователем полей в отдельной таблице неэффективно.
Две причины:
1. замедляется скорость запросов к такой таблице, поскольку это уже не простой select, а селект с поздапросом (в MS Access могут быть варианты без подзапроса, поскольку в его синтаксис позволяет сделать строки столбцами а вот MS SQL этого уже нет). Сортировка, например, по такому полю может вообще работать настолько долго, что ее придется отключать (то есть не реализовывать).
2. усложняется логика построения запросов, отсюда увеличивается вероятность допущения ошибки, усложняется поддержка.

Теперь по моей программе, в которой ничего такого нестандартного не усматривается. В том то и дело, что все очень просто, это чисто десктопное приложение. База данных не реляционная. Грубо говоря, там всего одна таблица (остальные идут чисто для реализации другой функциональности). В таком простом случае, я считаю, что принял правильное решение и пошел по самому простому пути. А опыт хранения определяемых пользователем полей в отдельной таблице у меня уже имеется в проекте с СУБД MS SQL Server. Надо сказать, что помимо существования 1 и 2 проблем имеется также проблема с типом полей, поскольку все значения таких полей хранятся в отдельной таблице в строковом типе. То есть потом, есть проблема правильной конвертации и т.п. А в моем случае все очень предельно просто, поле создается сразу нужного типа.
Так что это не случайное решение, а очень обдуманное.

в MS Access могут быть варианты без подзапроса, поскольку в его синтаксис позволяет сделать строки столбцами а вот MS SQL этого уже нет

Есть.
Да, в принципе, в MS SQL Server можно добиться того же эффекта использую несколько CASE (IIF в Access), но это хорошо подходит в простом случае, когда число колонок извесно заранее, например, в случае с кварталами. Их всегда 4. А вот, если число колонок неизвестно заранее (как в нашем случае), то хранимое представление уже не построишь.

Сортировка, например, по такому полю может вообще работать настолько долго, что ее придется отключать (то есть не реализовывать).

Если можно, приведи конкретный пример такого запроса.

Вот Вам пример в простом случае, когда юзер добавил новое поле к таблице Customers (пусть бд Northwind). Поле называется ContuctNumberOfChildren ("Количество детей контакта"). Надо выбрать все заказы из таблицы Orders, которые сделали покупатели, имеющие более 3-х детей.
SELECT * FROM Orders a INNER JOIN Customers b ON b.CustomerID = a.CustomerID WHERE b.ContuctNumberOfChildren > 3 ORDER BY b.ContuctNumberOfChildren

А вот в сложном случае, когда определяемые пользователем поля хранятся в отдельной таблице (а их значения в другой таблице) Вы, пожалуйста, напишите сами, если у Вас есть время/интерес.
Я Вам приведу описание этих 2-х таблиц:
1. UdfNames
UdfID int
UdfType - например, приложение дает пользователю создавать поля только: тестовый тип (text(255)), числовой (double), дата (Date/Time).
UdfName text(20)

2. UdfValues
UdfID
CustomerID
UdfValue text(255) - заметьте, это поле хранит все значения в строковом формате.

Успехов.

А изменение в рабочей базы структуры данных не усложняет логику?
В моем простом случае, нет. Это самый оптимальный вариант. А вот если у Вас, серверное приложение и Вы (по различным соображениям) стремитесь к тому, чтобы структура была жесткой, то Вам конечно надо использовать вариант с двумя таблицами.

Да, точно, неоднородны.
ContactNumberOfChildren - тоже поле числовое.

Вообщем, я учавтсвоавал в 3-х проектах, где бизнес требовал создания определяемых пользователем полей. Еще один проект с UD Fields протекал мимо меня, но на моих глазах. Моя программа "Анализ частных объявлений - Авто" - это вообще чисто факультативная работа, которую я и за серьезный проект-то не считаю. Так вот, в силу упомянутых причин 1, 2 и 3 (неоднородность) я бы сказал, обобщенно, что создавать UD Fields лучше изменяя структуру.
А вот если вы имеете какое-либо чисто физическое препятствие этому.
Например, ваш проект поддрживает репликацию бд. Синхронизируются толька данные, не структура (то есть и структура, но только в Master replica). Чисто физическое ограничение. То тогда, делайте вариант с двумя таблицами. Это мое ИМХО.

Можно привести пример такого запроса к локальной бд (насколько я понял прога у тебя работает локально) в котором сортировка работает "долго" ? \r
\r
Нет, в моей проге "Анализ частных объявлений - Авто" как раз реализован вариант, когда UD Fields создаваясь меняют структуру таблицы. И сортировка и выборка работают быстро.\r
\r
Привожу пример из другого (MS SQL Server) проекта:\r
\r
SELECT ContID, ContCode, Title, FirstName, LastName, (SELECT TOP 1 CASE ISNUMERIC(UdfValue) WHEN 1 THEN CAST (UdfValue AS REAL) ELSE 0 END FROM vContUdfValues WHERE UdfID = 11 AND vContUdfValues.ContID = Contacts.ContID) AS [Number of Children] FROM Contacts WHERE CompID=1405946239 AND (SELECT TOP 1 CASE ISNUMERIC(UdfValue) WHEN 1 THEN CAST (UdfValue AS REAL) ELSE 0 END FROM vContUdfValues WHERE UdfID = 11 AND vContUdfValues.ContID = Contacts.ContID)>3 ORDER BY [Number of Children]\r
\r
Здесь UDField \'Number of Children\' строится с помощь подзапроса.\r
Верояно, можно оптимизировать, применив несколько CASE. Но это дело будующего. Пока и так все работает. Дело в том, что это проект с OLAP- кубом, то есть все равно, потом будет строиться куб, а скорость построения куба не важна.\r
\r
Было у меня обсуждение проблем связанных с UDFields в форуме по MS SQL Server. Кому интересно может почитать /topic/32771&pg=1. Хотя тема начинается совершенно с другого, она потом затрагивает проблему "неоднородности" UDFields. Как раз когда я преобразовывал Varchar в Date.

хочу в выходные скачать твою прогу - поюзать ее по делу

Да, удачной работы тебе, Виктор, конечно. Но пока там эта функциональность (добавление полей пользователя) в демо версии отключена :) Просто, это было реализовано на DAO, а сейчас, при переходе на ADO, я как раз над этим работаю. Но все остальное работает нормально. А в след. версии, которую я соберу, наверное, в воскресенье, 2003-12-07, я включу добавление UDFields в демку.

У меня вопрос по библиотеке ADOX.
В этой моей проге есть ряд так называемых функций извлечения.
Например ExtractCarModelFromFullAd, ExtractColorFromFullAd и так далее.
Все они, как следует из названия, содержат логику построения аналитических полей (CarModel, Color ...) Так вот, есть у меня идея поместить все эти ф-ции в модуль самой субд и вызывать и выполнять их как некий аналог UserDefinedFunctions в MS SQL Server. В этом случае, продвинутый юзер, владеющий программированием на VB, мог бы сам подправить ту или иную ф-цию. То есть это было бы некое по с частично открытым программным кодом.
Я знаю точно, что с DAO такое не прокатывало, так может мне ADOX в этом поможет? Можно ли с помощью ADOX из кода на VB6 вызывать ф-ции в модуле бд, написанные на VBA?

Самое оптимальное в твоем случае писать и клиента на Акесе. Интерфейс откомпилировать в mde, а логику (функции юзеров) оставить в открытом mdb, которое подключать как библиотеку к mde.
Да это все понятно, что так можно, но не хочу. У меня больше опыта на VB6. Да и софтина не требует обязательной установки MS Access. Я встречал юзеров, которые даже MS Office принципиально не ставять, говоря, что все необходимое для них есть и без него.

Другой вариант использовать сохраненые скрипты, как описал am в http://am.rusimport.ru/MSAccess/f2.aspx?type=1&id=11831&page=4
(там много мусора - см. мои топики и ответы am)

Спасибо, Виктор. Очень интересно.
Только там не написано какую библиотеку подключить, чтобы создать объект ScriptControl.
Наверное, Microsoft Script Control 1.0 (msscript.ocx), не так ли?

Ладно, то, что я могу хранить скрипты моих ф-ций (VBScript) в текстовом файле (например) и давать их редактировать юзерам, я понял.

Меня теперь интересует, могу ли я все же хранить эти ф-ции именно в модуле самой бд? На языке VBA? То есть идея такая: юзер, если он "продвинутый", запускает MSAccess и редактирует эти (и только эти) функции по построению аналитических полей, используя встроенный в Access редактор VBA, сообщения о синтаксических ошибках и все другая функциональность в Access касательно написания VBA-кода. Могу ли я из кода на VB6 при помощи ADOX выполнять эти ф-ции?
Подозреваю, что нет.