access2007 runtime - opening another mdb
in [Help]
|
From: Roger on 5 Aug 2010 13:53 On Aug 5, 6:22 am, Marco Pagliero <mart...(a)web.de> wrote: > On 5 Aug., 01:52, Tony Toews wrote: > > > On Sun, 1 Aug 2010 12:37:29 -0700 (PDT), Roger wrote: > > >but my point is, the access runtime knows (should know the difference) > > >between launched from explorer vs launched from automation > > > How can it? > > I remember the old times of DOS and Assembler when we had tricks to > find out whether the program had been launched from within a batch or > by command.com or whatever. So I suppose Microsoft could fix the > problem if they only wanted. > > But I wonder how Roger happened to be the first person to stumble into > this difficulty since when the first runtime for Access hit the > market, wasn't it Access 2000? > > The only reason I can imagine why he needs to programmatically modify > from outside existing reports and forms would be that he has back end > and front end in one file, so this one is the only way to deliver new > versions of the program to customers without overwriting their data. > Maybe I'm mistaked? > > Greetings > Marco P all my data is on sqlserver 2005, so I only have frontends I have many front end applications that need to inter communication for example, I have a quoting application that needs to report a quality issue (QMS) the QMS system is it's own application so in access97, the quoting application uses this function Dim obj As Access.Application On Error GoTo fErr Set obj = New Access.Application With obj .Visible = True .RefreshTitleBar .OpenCurrentDatabase "another.mdb" .run "createQMS" end with to start to QMS application and run a function that opens a form to create a new quality problem I have other applications that interoperate this way with access2007, I've found that I can SHELL to start the QMS application, and I can use the command line to pass in the function to run, with parameter and the QMS application's autoexec macro parses out the command line and behaves accordingly
From: David W. Fenton on 5 Aug 2010 14:47 Marco Pagliero <martesi(a)web.de> wrote in news:9c8456ec-d164-4adf-a65a-3ef8ca360343(a)u26g2000yqu.googlegroups.co m: > when the first runtime for Access hit the > market, wasn't it Access 2000? The runtime existed at least for Access 2, though it was called the ADT (Access Developers Toolkit). I don't know when it was implemented, but it was already a mature platform by that point. -- David W. Fenton http://www.dfenton.com/ contact via website only http://www.dfenton.com/DFA/
From: David W. Fenton on 5 Aug 2010 14:49 Roger <lesperancer(a)natpro.com> wrote in news:45e59b82-c838-4ed2-a681-378709b93915(a)q21g2000prm.googlegroups.co m: > all my data is on sqlserver 2005, so I only have frontends > I have many front end applications that need to inter > communication for example, I have a quoting application that needs > to report a quality issue (QMS) > the QMS system is it's own application > > so in access97, the quoting application uses this function > Dim obj As Access.Application > > > On Error GoTo fErr > Set obj = New Access.Application > With obj > .Visible = True > .RefreshTitleBar > .OpenCurrentDatabase "another.mdb" > .run "createQMS" > end with > > to start to QMS application and run a function that opens a form > to create a new quality problem I would never do this kind of thing. Do you not know about Application.Run? It's how you implement an add-in, and there are lots of possibilies there that would not require automating the other application. Of course, how hard that is to implement would depend on the level of complexity of what you're using from the other application, as well as various issues with what data to use and so forth, but all of those are issues that can be addressed and still work with the runtime. -- David W. Fenton http://www.dfenton.com/ contact via website only http://www.dfenton.com/DFA/
From: Roger on 6 Aug 2010 05:47 On Aug 5, 12:49 pm, "David W. Fenton" <NoEm...(a)SeeSignature.invalid> wrote: > Roger <lesperan...(a)natpro.com> wrote innews:45e59b82-c838-4ed2-a681-378709b93915(a)q21g2000prm.googlegroups.co > m: > > > > > > > all my data is on sqlserver 2005, so I only have frontends > > I have many front end applications that need to inter > > communication for example, I have a quoting application that needs > > to report a quality issue (QMS) > > the QMS system is it's own application > > > so in access97, the quoting application uses this function > > Dim obj As Access.Application > > > On Error GoTo fErr > > Set obj = New Access.Application > > With obj > > .Visible = True > > .RefreshTitleBar > > .OpenCurrentDatabase "another.mdb" > > .run "createQMS" > > end with > > > to start to QMS application and run a function that opens a form > > to create a new quality problem > > I would never do this kind of thing. Do you not know about > Application.Run? It's how you implement an add-in, and there are > lots of possibilies there that would not require automating the > other application. > > Of course, how hard that is to implement would depend on the level > of complexity of what you're using from the other application, as > well as various issues with what data to use and so forth, but all > of those are issues that can be addressed and still work with the > runtime. > > -- > David W. Fenton http://www.dfenton.com/ > contact via website only http://www.dfenton.com/DFA/- Hide quoted text - > > - Show quoted text - in access97, application.run is what I used to run a function in another MDB application (per my code sample) application.run doesn't work with the runtime cause I can't create a new access.application
From: David W. Fenton on 6 Aug 2010 13:09
Roger <lesperancer(a)natpro.com> wrote in news:1196cefb-3a29-493e-8942-a146317a6df5(a)x21g2000yqa.googlegroups.co m: > On Aug 5, 12:49�pm, "David W. Fenton" <NoEm... >> I would never do this kind of thing. Do you not know about >> Application.Run? It's how you implement an add-in, and there are >> lots of possibilies there that would not require automating the >> other application. >> >> Of course, how hard that is to implement would depend on the >> level of complexity of what you're using from the other >> application, as well as various issues with what data to use and >> so forth, but all of those are issues that can be addressed and >> still work with the runtime. > > in access97, application.run is what I used to run a function in > another MDB application (per my code sample) > > application.run doesn't work with the runtime cause I can't create > a new access.application You don't *need* to create a new application to use Application.Run -- you're running code/forms/reports in another database, but in a single instance of Access. Consider the fact that DBEngine.Databases is a collection that can have more than one database in it. When you use Application.Run, you are opening another database with the existing instance of Access, so that DBEngine.Databases.Count should be 2 (or more, perhaps), with one being the CurrentDB open in the user interface, and the other being the database with the code/forms/reports being executed via Application.Run. That's the whole point of my mentioning it, because it entirely avoids the problem with the runtime of being unable to initialize another instance of Access -- you don't *need* another instance, because you're using the stuff from the other database within the original instance of Access. This is not to say it's *easy* to do that (if you need forms that are bound to linked tables, you have to have the same linked tables in the CurrentDB database as they are bound to in the external database you're using via Application.Run). But it is at least *possible*, whereas initiating another instance of the runtime isn't. -- David W. Fenton http://www.dfenton.com/ contact via website only http://www.dfenton.com/DFA/ |