Здравствуйте!
Написал следующий код:

Set cnn = New ADODB.Connection
Dim rs As New ADODB.Recordset
Dim cmd As New ADODB.Command

strCnn = "DRIVER={Microsoft Visual Foxpro Driver}; UID=; Deleted=Yes; Null=Yes; Collate=Machine; BackkGroundFetch=Yes; Exclusive=No; SourceType=DBF; SourceDB=D:\DBF"
cnn.Open strCnn
Set cmd.ActiveConnection = cnn
strSql = "SELECT splt1(nm_frm) as name1 FROM tex"
rs.Open strSql, cnn, adOpenKeyset, 1

Почему-то выдается сообщение, что OBDC не поддерживает требуемый запрос, а именно из-за пользовательской функции splt1, который описан как public. Если использовать встроенные функции (Left, Mid, ...), то проблем нет.
Почему так происходит, что тут не так?

1) А как именно?
2) А почему, если использовать встроенные функции - все в порядке?

Меня как раз и интересует, каким образом можно заставить сервер понимать пользовательские функции.

Т.е. объявить где-то, зарегистрировать чего-то и т.п.

Неужели никто не сталкивался с такой ситуацией?

Есть в соседнем отделе БД - на DOSовской FoxPro2.6, плоская, старая, но работающая.
Хочу, используя VB, получить возможность формирования нужных мне отчетов (которые немножко отличаются от ихних отчетов), при этом не трогая саму базу и не мешая их работе.
Изменения при формировании отчетов небольшие, но если данные сначала считать, а потом обрабатывать - уходит много времени.

Думал просто с помощью SQL-запроса сразу сформировать базу с необходимыми изменениями (это возможно), но столкнулся с неприятием пользовательской функции. Как видите, отдельного SQL-сервера нет, хранимых процедур - тоже.

Можно конечно запустить SQL-запрос сначала на FoxPro или на ACCESS (предварительно импортировав базу) - там действительно проблем нет, но хотелось бы сделать все на VB и динамически.