In Access, what is the difference between these two statements?
DBEngine.BeginTrans
and
DBEngine.Workspaces(0).BeginTrans
The documentation for both leads to the same place.
Have a look here: DAO Workspace
And then here: DAO Workspace: Opening a Separate Transaction Space
(The links are for MFC, but they're applicable to whatever you're coding in.)
DBEngine.Workspaces(0) is the default workspace. Other workspaces can be created, which let you work with separate sessions; the idea is that BeginTrans and EndTrans apply to the whole workspace, but if you need to do stuff outside that transaction, you can create another workspace and use it independently of your transactions in the first workspace.
Personally, I never had occasion to use more than one workspace when doing DAO in VBA. * shrug *
My own answer:
It appears that DBEngine.BeginTrans and DBEngine.Workspaces(0).BeginTrans do the same thing because this code works (see below). "Workspaces" is the default member of DBEngine.
Dim db As Database
Set db = CurrentDb
DBEngine.BeginTrans
db.Execute "Update Table1 SET CITY='Newark'"
DBEngine.Workspaces(0).Rollback
In the Access application interface, you can only have one database container open at a time. In VBA code, you can open multiple database instances within a Workspace. See the help file documentation for the Workspace.OpenDatabase method (or http://msdn.microsoft.com/en-us/library/bb243164.aspx) for an example where more than one Database is opened in one Workspace.
One would infer that when transactions are supported by all of the underlying Databases that are open in a Workspace, the BeginTrans method of the Workspace would apply across all of the databases. I suspect there be dragons there, but I'm sure it would work with two MDBs inside of one Workspace. When there's only one database open in the Workspace, Workspace.BeginTrans and Database.BeginTrans are indeed the same.
As Spock once said, a difference which makes no difference is no difference...
Related
What are the differences between the following sets of Microsoft Access VBA collections..? Some of them seem to point to the same data & child objects, but through different conduits. I'm thinking the DAO objects are DBMS-specific, but Access.⃰ Code.⃰ and Access.⃰ Project.⃰ are not, and get connected through Access. There is ADODB, which is another beast entirely. Also, it seems some of the collections may not exist if there no child objects of that type.
Given the mentions of SQL features, there seem to be three scenarios to be concerned with, but it's difficult to grasp:
A standalone ACCDB file.
A split database with two or more ACCDB
files.
An Access frontend to an SQL server.
Object set #1:
Access.CodeData.AllTables
Access.CodeData.AllQueries
Access.CodeData.AllFunctions
Access.CodeData.AllDatabaseDiagrams
Access.CodeData.AllStoredProcedures
Access.CodeData.AllViews
Access.CodeProject.AllForms
Access.CodeProject.AllMacros
Access.CodeProject.AllModules
Access.CodeProject.AllReports
And of course CodeData vs. CurrentData and CodeProject vs. CurrentProject.
Object set #2:
Access.Application.CodeData.*
Access.Application.CodeProject.*
Object set #3:
Access.Application.CurrentDb.QueryDefs (DAO.QueryDefs)
Access.Application.CurrentDb.Relations (DAO.Relations)
Access.Application.CurrentDb.TableDefs (DAO.TableDefs)
The biggest difference is in the type of database you are working with. A standard Microsoft Access database (*.accdb) will primarily use the CurrentDB/CodeDB object to reference the database objects.
An ADP Project, on the other hand, is kind of a hybrid with some data on the SQL server (tables, queries, etc...) accessed through CurrentData/CodeData and other objects like forms and reports residing in the *.adp file and accessed through CurrentProject/CodeProject.
The difference between CurrentDB and CodeDB comes into play when you have multiple database files involved, such as other Access databases referenced as library databases. Those library databases might have functions to interact with the parent application, and others that reference the library.
As you should already know (since I told you here), you can store code in external databases, and refer to that code from another database.
The code in this external database might rely on certain tables, queries and forms to be present. But since it's ran on another database, they might not be.
That's where CodeDb, CodeProject and CodeData come in. They're fully equivalent to the variants starting with Current, only refer to the database where the code is stored, instead of the database which is currently open.
Differences between CurrentDb, CurrentProject and CurrentData is really asking for differences between apples, pears and oranges. They're all objects, but fulfill different functions. As ThunderFrame noted, CurrentDb is mostly DAO, and CurrentProject contains some ADO functionality (mostly just the connection), but also functions to influence the VBA part of the database, the database path, and many other functions. And CurrentData is something else entirely.
In Access, the CodeDB and CurrentDb functions return DAO.Database objects.
CodeDb is the database or add-in, within which the code is running (which might not be the same as the CurrentDb.
CurrentDb is the currently active database (not an add-in).
Access 2002/03 added ADODB, and so they added CurrentProject and CodeProject functions for returning the ADO equivalents of CurrentDb and CodeDb, but being ADO, they have very different methods and properties.
Looked around and found a variety of answers, but nothing recent that really compares these options pro and con. So I thought I'd ask the community to weigh in on which route you prefer and why.
Background
This is what we have:
Common set of Access modules & classes used in numerous protocol databases (Access 2010 *.accdb split front/back-ends)
Front-ends link to back-end database tables & code (linked dbs)
Back-ends contain protocol specific data & code
Common module/class database shouldn't be directly edited by users
Knowns
Add-ins & db reference databases:
Require re-distribution each time they are changed (even if no code is changed within them).
Must be edited within their IDE vs. the IDE of the protocol database (or you'll lose your edits since that db isn't the common code's)
Questions
How should the common module/class database be connected to the protocol databases?
linked database just like back-ends are
attach it as a reference in the IDE (Tools > Reference)
create an add-in and add it as a reference
How would you do it and why?
What are the pros/cons?
Which option would maximize performance?
I have several variations of the following code lying around, I think this one is most applicable to your situation (it pulls modules and forms from a database, overwriting existing ones, as soon as the database is started).
Public Sub ImportModules()
Dim ImportDbLocation As String: ImportDbLocation = CurrentProject.path & "\ModuleDb.accdb"
Dim ObjectsToImport As Recordset
Set ObjectsToImport = CurrentDb.OpenRecordset("SELECT * FROM Objects IN """ & ImportDbLocation & """")
Do While Not ObjectsToImport.EOF
On Error Resume Next
DoCmd.DeleteObject ObjectsToImport!ObjectType, ObjectsToImport!ObjectName
On Error GoTo 0
DoCmd.TransferDatabase acImport, "Microsoft Access", ImportDbLocation, ObjectsToImport!ObjectType, ObjectsToImport!ObjectName, ObjectsToImport!ObjectName
ObjectsToImport.MoveNext
Loop
End Sub
This code is triggered from the AutoExec macro in the front-end databases.
The database referred to as ImportDbLocation is the database containing all modules and forms I want to import. It contains a single table named Objects. This table has two columns, one named ObjectName containing the names of all objects that should be pulled, and one named ObjectType, which is a lookup field that corresponds with the acObjectType enum (some irrelevant objects removed).
Advantages:
You get a fresh copy of all modules in the database, making sure any overwrites are irrelevant.
You can add a third column to the Objects table to filter out objects for a specific database, thus selectively pushing some objects to some front-ends, and others to others (and a fourth one to specify the name of the objects in the ModulesDb file, to use multiple variants of the same form for different front-ends).
You have all code in the front-end, so no weirdness with external files and references
You can also use this code to pull any other type of objects you want (in my case mainly queries and forms)
Disadvantages:
Load time increases (normally by a tiny bit, but dependent on how many objects are imported, it might be long)
Modules are visible and readable for end-users (technically also modifiable, but any changes are undone on database load)
You can't modify the module doing the import this way
You NEED proper security settings, else users will get spammed with security popups on every database open
I also have a variant lying around that asynchronously pushes the modules from a separate thread to the database when opened, and I have another implementation that allows me to selectively move modules to front-ends after doing modifications.
I can share them if needed, but haven't yet implemented the asynchronous one in a production environment (still a work in progress, it should save on load time and can push all modules)
First a big "thank you" to #Erik and #Gustav for your inputs.
Solution
The solution opted for in my use case was to use a common reference library database that houses modules and classes.
While I considered #Erik's solution, in the end copying over the modules and classes into each protocol database was a bit too much like sending out copies of them which could then devolve from the master modules/classes. This in part was one reason to shift to the single reference database - to avoid propagation into the other databases so there would be a single code source for them.
Caveat: If there are performance issues with the reference library solution, classes & modules may have to be pulled from the common library database ala #Erik's solution.
Database as Reference Library
The common modules and classes are contained within a database (*.accdb). Whenever the code is desired in another database, a reference is added like referencing any other code library (VB IDE - Tools > References). The only difference is that you Browse... to the library and make sure you select Microsoft Access Databases (*.accdb) in the search filter.
If the reference library database is kept in a common location, there shouldn't be issues with re-referencing, although re-connecting the reference is easily done (same as connecting in the first place).
I've also separated out common version control and development modules into similar separate databases that can be referenced when desired during development and de-referenced when a given database goes to production.
Development "Gotchas"
Actually these are more considerations/things to remember than true "gotchas":
- Edit library classes & modules in the library database
If you edit a class or module from the database that references the library database you will lose the edits as soon as you close the database you were working in.
You can try out edits from the database you're working in - the code will run, but it doesn't save.
I often have Notepad++ or OneNote open to copy & paste over code I'm testing to the library database. That way I can continue working on other areas and have a set of changes to update the library database.
- Compile the library database before using its components in the referencing database
This is more a workflow issue - make sure you save & compile in the library database, then open your referencing database after you've completed your changes and closed the library database first.
Resources
Here are some links which proved helpful:
Using a centralized vba module in multiple access databases
Using VBA Code Libraries in Access Database Applications
Referencing VBA Projects as Libraries
Demonstration Applications & VBA Code Libraries
Classes in VBA
Using Database Library Files in Your Access Application
Object Oriented VBA: Design Patterns: Simple Factory
Object Oriented VBA: Static Classes
The 6th reference (available only via the internet archive) has been particularly helpful in sorting out how to properly instantiate classes. In the end I opted to create a single Factory class (static class) with multiple functions (one per class - e.g. NewClassABC()) that instantiates the class within the common reference library database.
So far, so good.
The reference library database has the code in one place and other protocol databases can be updated to it when desired. No dealing with multiple copies and versions of the same module or class.
Hope this helps others looking for a "common" library type solution.
I am looking for a solution to effectively communicate between two running MS Access applications.
The approaches I tried so far is to use a common linked table and to use MSMQ service for communication. Both approaches work, but there is no way to "push" the data or command from one application to another and since MS Access doesn't support multi-threaded execution of VBA code, it is very difficult to implement polling without performance disadvantages.
Same time, VBA does support the addressof operator (from version 2000) that means we can also theoretically implement call-back functions in VBA and MS Access. But I have never seen any example how this can be used for inter-process communication and would appreciate any minimal example how I can send a string from one MS Access application to another without monitoring a shared table all the time.
You can use GetObject() to return the Access.Application object from another running db. With the application object you have access to just about everything you might need. Here's a contrived example of opening a form (but you can do a myriad of other things with the Application object):
Sub TestInterop()
Const mdbPath As String = "C:\OtherApp.mdb"
Dim OtherApp As Access.Application
Set OtherApp = GetObject(mdbPath)
OtherApp.Visible = True
OtherApp.DoCmd.OpenForm "Accounts"
End Sub
If the program is not already running, the GetObject() call will start the application (you would need to be careful if you have multiple versions of Access installed as it's difficult to know at runtime which version would actually open the .mdb). However, if GetObject() needs to start the app, it will do so with the visibility set to False, so we explicitly set it to True. If the app is already running, setting its Visibility to True will have no effect.
Consider it a wild idea, but may be put all your tables into sql express and/or sql ce and make look like a frontend to those tables?
We have developed a consolidation function that will be used by other processes and want to position the function in its own MDB (call it "remote") so that it can be referenced and called from "caller.mdb" when its needed. The function is designed to return an array and works great when executed called directly from within "remote." However, with "remote" properly referenced in the "caller" VBA project, when "caller" makes the call the function returns errors. We get a variety of errors such as
3078: Jet cannot find the input table or query
QUESTION. Within "remote", how does one properly set references to the db and its local objects (e.g. one table and several queries including INSERT and UPDATE queries)? CurrentDB is apparently not the answer; we have also experimented with the AccessObject and CodeData objects. "Remote" and "caller" currently reside on the same drive, so that wouldn't seem to be the problem.
Instead of CurrentDb you could use with CodeDb wich points to the mdb currently executing the code.
Set db = CodeDb
The way Access itself does this (with all the wizards, which are all programmed in Access), is to use Application.Run. It does mean the code you're calling has to be a function, though it doesn't matter what it returns. Application.Run requires no references, just a path:
Application.Run("MyCodeDatabase.MyFunction()")
Obviously, if the code database is not in the path that Access uses (which includes its own app folders (including the app-specific folders in the user's profile) and the folder where your main application front end is stored), you'll need to specify the full path.
Application.Run() is a function that returns a value, but it is typed as variant. This may or may not work with your array. It's not clear from the object browser whether or not the arguments are passed ByVal or ByRef, but if they are ByRef (which is what I'd expect), you might just pass the array in and let the function work on it and then use it after the code in the remote database has completed.
On the other hand, the arguments are probably variants, so there's not much difference between that approach and just using the structure returned by Application.Run().
Marcand gave you the answer to your immediate question. There are other problems and irritations when it comes to using add-ins or referenced Access databases. See my Add-in Tips, Hints and Gotchas page.
There are a number of differences and nuances to calling forms and functions through a reference in a another MDB or ADP. I have run into issues in both situations, and what you are referring to as the "remote" database, I refer to as a central library.
At my Tips and Tricks page at http://www.mooresw.com/tips.php, I have pages devoted to programatically changing references, getting Access to search for the referenced file instead of having a broken reference, and calling forms through a reference.
Programatically changing references is needed when you publish the database from the development environment to the user or production environment. When working in the development folder, it's fine for the program to have a reference to the central library directly, but we wouldn't want code that 20 users are running tying up the central library in our development area. (An MDB file opened through a reference gets locked just as though your users were opening it directly)
The situation of running a form in a central library (or "remote" database) where there are no links or tables can be tricky. In that situation I've chosen to open a connection to the "caller.mdb" using ADO code with a Jet connection string in the open event of the forms. Doing so provides the ability for the code in the form (or functions in the library) to gain access to the tables and queries in the calling mdb.
For further information, see my pages at the tips link above, and in particular, see:
http://www.mooresw.com/call_a_form_in_another_MDB_through_a_reference.php
which I believe is most relevant to your situation.
From the documentation, I would expect adModeShareDenyWrite to be the way, but it's not working right.
I'm using an Access database via ADO. My connection string says Mode=8, which is adModeShareDenyWrite. But when I try to delete a row from a table, I get:
Unspecified error, Description:Could not delete from specified tables., Source:Microsoft JET Database Engine
In other words, the setting is preventing ME from updating the database using my OWN connection.
I found a couple other posts on the web reporting the same thing, the adModeShareDenyWrite setting used with Access not working as documented.
I am looking for a solution that doesn't involve an administrator changing permissions. It needs to be something that my program can control.
My motivation here is to minimize the chances of database corruption. One of the causes of mdb file corruption documented by Microsoft is two apps writing to the same db. So, I want to make sure that only one app can have a write connection to the db. Others can read, but should fail when they try to write. Whoever makes a connection first wins.
Cory Trager wrote:
My motivation here is to minimize the
chances of database corruption. One of
the causes of mdb file corruption
documented by Microsoft is two apps
writing to the same db. So, I want to
make sure that only one app can have a
write connection to the db. Others can
read, but should fail when they try to
write. Whoever makes a connection
first wins.
Why are you worrying about it? Jet is by default a multi-user database engine. If somebody else is updating a table, the data pages involved will be locked as read-only (in the state they were before the write began).
There is no realistic reason to fear corruption from mere multi-user interaction. Corruption of Jet databases usually happens because of dropped connections or an interruption of the connection during a write (such as users who force quit an app that is not responding as fast as they want).
I think your fear of corruption is misplaced.
On the other hand, you should still be able to open with an exclusive lock, and I'm not sure why it's not working. Have you considered using DAO instead of ADO to manipulate Jet data? Given that it's the native data interface (instead of a generic interface layer), it ought to be easier.
One solution is to give them access to a copy of the database. They can change whatever they want, but it won't keep past your copying it over with the master.
I suppose you access here an MDB file from a client interface, whatever it is, and others can also connect to the same file at the same time. When you use adModeShareDenyWrite in your connection mode, it means that you can still share the data with others (no locks of any kind on tables or records in the MDB file) but it can't be modified (this is why you get an error).
One solution would be to manage your connection parameters, with something like that:
(where you have a user object with a '.role' property, or anything equivalent ...)
if activeUser.role = "admin" then
m_connectionMode = adModeWrite
else
m_connectionMode = adModeShareDenyWrite
endif
Then you can open your ADO connection with the parameter m_connectionMode. Administrators will be given the right to insert/update/delete while other users will ony be able to view the data. This means you have somewhere in your program, or ideally in a table, some data saying who is what in your application.
EDIT: Following multiples comments with Corey:
You won't be able to do what you want to do in a straight way. My proposal: when the app accesses the database, it checks for a special file in the .mdb folder (whatever the file is).
If this file exists, the app opens a "read-only" connection.
If this file does not exist, the app creates the file (you can create one for example with "transferDatabase") and open a read-write connection. Once you quit the app, destroy the file.
If you have multiple users connecting to an access database across a network you might want to consider upgrading to SqlServer instead of using Access.
Corey Trager wrote:
I am looking for a solution that
doesn't involve an administrator
changing permissions. It needs to be
something that my program can control.
Well, if the problem is due to NTFS permissions being read-only for the user, there isn't a thing you can do to make the MDB writable. You don't specify where the MDB is stored, on a server or on a local hard drive, but in either case, for a user to have WRITE permissions on the MDB, NTFS permissions have to be set to allow it (for a share on a server, it has to be allowed both on the SHARE and on the underlying file). If it's a local file, the best solution is to make sure that you're storing the file in a location in which user-level logons have full WRITE permission. This would be anywhere in the user profile, and just about nowhere else.
That said, I'm not really suggesting that this is the source of your problem (I really can't say one way or the other), just pointing out that if it is the cause, then there's not a damned thing you can do programmatically to work around it.