[AccessD] Runtime Limitations?

Dan Waters dwaters at usinternet.com
Fri May 28 13:20:33 CDT 2004


Thanks Marty!

I'll save this one.

Dan

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly
Sent: Friday, May 28, 2004 12:59 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Runtime Limitations?

Nope you can call or bind most com objects.
By either early binding by setting a reference and dimensioning and 
setting the object
or by late binding using  getobject createobject. The problem being the 
references may not be correct
for another.machine using early binding but you can use intellisense to 
look up methods in design mode.
However  you can more easily trap for errors using late binding but 
slower intial execution.
It is a swings and merrygoaround difference. Your choice.


CodeDb Function Example, assume say you have an addin code library in an 
MDE file and call one of its functions.
The CodeDB statement determines the name of the database mde or mbd file 
where the running  code resides.
If you don't do this it will assume that the table resides in the 
calling mdb.

The following example uses the CodeDb function to return a Database 
object that refers to a library database. The library database contains 
both a table named Errors and the code that is currently running. After 
the CodeDb function determines this information, the GetErrorString 
function opens a table-type recordset based on the Errors table. It then 
extracts an error message from a field named ErrorData based on the 
Integer value passed to the function.

Function GetErrorString(ByVal intError As Integer) As String
    Dim dbs As Database, rst As RecordSet

    ' Variable refers to database where code is running.
    Set dbs = CodeDb
    ' Create table-type Recordset object.
    Set rst = dbs.OpenRecordSet("Errors", dbOpenTable)
    ' Set index to primary key (ErrorID field).
    rst.Index = "PrimaryKey"
    ' Find error number passed to GetErrorString function.
    rst.Seek "=", intError
    ' Return associated error message.

    GetErrorString = rst.Fields!ErrorData.Value
    rst.Close
End Function


Dan Waters wrote:

>Marty,
>
>I thought I read that I could only use code that is part of Access.  For
>example, no automation of Word, Excel, or other applications.
>
>It wasn't as specific as CurrentDB, or CodeDB (what is CodeDB?).
>
>Do you know where I could find a useful list of the differences between
>runtime Access and the full version?
>
>Thanks,
>Dan
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly
>Sent: Friday, May 28, 2004 11:45 AM
>To: Access Developers discussion and problem solving
>Subject: Re: [AccessD] Runtime Limitations?
>
>Are you referring to the proper use of CurrentDB and CodeDB in addin  MDE's
>
>Dan Waters wrote:
>
>  
>
>>Hello to All!
>>
>>
>>
>>I seem to remember reading somewhere that when you are using an Access
>>Runtime installation, you cannot refer to other object models in code.  Is
>>this correct?  I read a couple of articles in MSDN, but couldn't find
>>mention of this limitation.
>>
>>
>>
>>I tested using the /runtime switch.  My code uses API's, File System
>>    
>>
>Objects
>  
>
>>(FSO), and spellchecking (Word), and all worked fine.
>>
>>
>>
>>TIA,
>>
>>Dan Waters
>>
>>
>>
>> 
>>
>>    
>>
>
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada



-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list