Jet SQL remote execution problem

[archer2002]

Hello there.
I have such problem:
I have simple VB module in Access with some function

Public Function ABC() as String
...
ABC = "Hello all"
End Function

When I access this function from Access, using
SQL: SELECT ABC();
I have normal result "Hello all".
When I access this funciton form external C# application using OleDb SQL call I receive SQL error "Unknow function ABC".
Does that means, that VB modules are not recognized as .MDB data part.

SandboxMode is disabled.
Please, help.

 

[dilettante]

Yep, VBA code stored in an MDB file is only processed by the Access runtime.

An external program using ADO or ADO.Net doesn't use the runtime, instead it processes the data using the OLEDB Provider for Microsoft Jet Databases. This gives fairly full access to tables, queries, and relationships, but it can't make use of forms, modules, or reports. Through ADOX a lot of metadata can be examined or manipulated as well: the MDB's schemas and meta-schemas including user information. JRO offers database repair and compaction as well as replication facilities.

I haven't seen evidence of an ADOX.Net but I haven't looked yet either. I don't anticipate a JRO.Net at all, considering the comments in the release notes for recent MDAC editions about Jet (Access) databases going away. Personally I hope this last part is a crock - I need Jet desperately for a project I'm working on, and MSDE won't cut it. But it seems more than a rumor that new versions of Access will be MSDE-only, able only to "upgrade" existing MDB files to MSDE databases.

Many Access data types are really "fictional" and not native to the underlying database. For example the Access "hyperlink" type is really a BLOB field (like a memo) with an extended attribute set to indicate that it is a hyperlink. The Access runtime masks this for the Access form and module developer, and even provides SQL string processing to simulate it as well as the HyperlinkPart() function in VBA. And the list goes on.

Basically, all of the stuff that a "split" Access application would store in the client "front-end" MDB is stuff an external program doesn't use.