Opening one database from another

[ChipR]

I was able to open my other DB manually with no problem. I'll try Shell today, and maybe a global application object and see how it goes.

On that topic, is there some reference you would recommend where I can learn about declaring functions like Shell, and what other functions are available? I'm not sure where these come from.

[tomric]

I got the shell method to work, I spent last night going over it and the dummy here should learn how to type. Thank you all for the help in this.

[NeoPa]

Oh I wasn't saying Shell() doesn't work, I was stating that I recommended Shell in general because I think this should work across all versions of access. Whether it is Shell() or ShellExecute(), I just recommended ShellExecute() because this is what I have used since I started working in Access professionally and I never had an issue, and I go by the Motto If it ain't broke, or badly designed, don't mess with it! =)

Sorry for the delay responding. Good motto - Like the slight adjustment there :D

My only preference is that one is an inbuilt Access function while the other involves OS calls. Not a problem, but personally I always go for the inbuilt where available. It involves less fiddling with declarations etc.

[NeoPa]

On that topic, is there some reference you would recommend where I can learn about declaring functions like Shell, and what other functions are available? I'm not sure where these come from.

I'm not clear which version you're referring to here Chip.

1. If it's Shell(), then nothing is required. It's found in the VBA library.
2. If it's ShellExecute(), then this is a little more complicated as you need to declare this function as something defined elsewhere. I'm not sure where ShellExecute() is defined, but I can give an example of a similar function I use in my OS library.
   

   Private Declare Function CreateProcessA Lib "kernel32" ( _
       ByVal lpApplicationName As Long, _
       ByVal lpCommandLine As String, _
       ByVal lpProcessAttributes As Long, _
       ByVal lpThreadAttributes As Long, _
       ByVal bInheritHandles As Long, _
       ByVal dwCreationFlags As Long, _
       ByVal lpEnvironment As Long, _
       ByVal lpCurrentDirectory As Long, _
       lpStartupInfo As typStartupInfo, _
       lpProcessInformation As typProcInfo) As Long

   NB. Because these OS provided functions are generally written to a standard that VB doesn't support natively, a bit of creative declaration is required. EG. lp... refers to Long Pointers and in VBA we need to store it in a simple Long. We cannot use these values as such, but can only pass them across.
   
   The good news is that most functions have examples out there on the web of how they can be used in VBA. Furthermore, the Lib "kernel32" part is explicit and means you don't need to add a reference to any VBA library.

[ajalwaysus]

Sorry for the delay responding. Good motto - Like the slight adjustment there :D

My only preference is that one is an inbuilt Access function while the other involves OS calls. Not a problem, but personally I always go for the inbuilt where available. It involves less fiddling with declarations etc.

I definitely agree, but I have been burned a couple of times using the inbuilt functions. Example, I was using the Environ("Userna me") and for some reason it didn't work on some PCs and because i couldn't figure it out, so I resorted to...

Private Declare Function apiGetUserName Lib "advapi32.dll" Alias "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long

So I guess I am a little biased, cause I don't like being burned. =)

Good motto - Like the slight adjustment there :D

Well my professor always told me:
1. Your code must be functional, and effective.
2. It must be a good design.

So I built that motto around that. =D

-AJ