According to http://support.microsoft.com/kb/288902/en-us
You can attach to a specific instance
if you know the name of an open
document in that instance. For
example, if an instance of Excel is
running with an open workbook named
Book2, the following code attaches
successfully to that instance even if
it is not the earliest instance that
was launched:
Set xlApp = GetObject("Book2").Application
Th example works for Excel, mainly because the "Document Name" is nearly the same as the filename. I need to get this to work for Access.
I have users running multiple instances of different Access Applications (.ADP) and I need to get one with a specific name. I do NOT know the complete filepath, otherwise I could do a simple
Set app = GetObject("c:\my\app\myapp.adp", "Access.Application")
Currently, I go with calling
Set app = GetObject(, "Access.Application")
and check the returned Application.Name. If it's good, I use it to call some functions on it, if not it fails. I have heard about the Running Objects Table, but since I have to get the object inside a VBScript, it's a bit too much API-calls.
Bottom Line:
What is the correct "Document Name" of an Access ADP to use in the GetObject("Document Name") call and what type of object does it return?
Coming back to this question because #phoog posted an answer, it occurs to me that since Access can have only one database open at a time, you'd need to look at each instance of Access and check its CurrentDB.Name. Now, with an ADP, I don't know what you'd check instead, but perhaps it's CurrentProject.Path.
I don't believe any of that actually addresses the original question, which seems to want to find the instance with just the filename, but I don't think that even if that worked it would be a good idea. You could easily have independent Access apps that return the same application name and filename but are stored in different locations in the file system.
You probably want to read this: http://support.microsoft.com/kb/147816
Unfortunately, it looks like "Document Name" has to be the mdb file, so if you don't know the file path, you're not going to be able to use "Document Name".
In addition to the fact that Excel can have multiple documents per instance, Excel also prevents you from opening two documents with the same name, even if they are in different folders and you are opening them in different instances of Excel.
On the other hand (to address David-W-Fenton's comment), Access does allow you to open multiple instances of the same database (not to mention different databases with the same name), as long as you don't open any instance in exclusive mode.
This is further evidence that the way Excel registers its documents in the ROT is very different from the way Access does so.
Related
So after some digging I realize that there is no built in user level security option for Access 2007. What I need to do is restrict records that users can edit based on who is logged in (they can see all the data but only edit their own). I was thinking that I could make a log in form and assign passwords and go from there, but I was wondering if there was a better method to do this.
For user privileges for read-only, read-write on forms in the database, we implemented following tables, logic.
I created a privilege table along with log-in table. Each screen in the database will have Read-only or Read-write privilege to each user. I inserted all the screen names into privilege table. Another table UserPrivilege will have users and their privileges. Assigning privilege to an user will be done only by Admin user.
A function at start of each form check swhether a specified user is allowed to view or edit form. If he/she is given read-only, we will lock all controls looping thr' controls on the form. Else, nothing to do. OR keep all the controls read-only at design them and unlock them thr' code for write privilege.
The database window is kept hidden when a version to end user is delivered. This prevents usual , simple view to tables in the database, opening forms , reports object in database window. After making mde/accde few more tweaks can be done so that user is not easily able to view tables directly. by-passing startup, special keys etc.
I have been facing this problem too. My solution (which hasn't been broken yet) is to do exactly that. Make a user's table with passwords and a log in form which reads the table for User name, password and user type. I have used two ways to proceed from there: Case statement to open specific navigation forms for that user's functions or a global variable (in a module (enumeration helps)) and an getter function that is checked within each form's open events and changes properties like AllowEdits, and AllowAdditions and even cancel the form opening if it's administrative stuff.
The most important part of this set up is making sure the users are using Access Runtime. If they use the Access version you are developing in they can snoop a little bit and get around this.
Make sure you hide the user's table.
Access runtime can be forced by making a shortcut to the DB and adding /runtime to the end of the shortcut path (with a space).
It's not perfect, but it works for my purposes and It might work for your's.
I did dot this in 2010, but 2007 should be pretty much the same.
Assigning username/passwords in Access (especially with an access back end) has a number of critical issues that are worth pointing out. Firstly, if you don't encrypt your DB, then any of your users who are savvy enough to go looking for it will be able to find it, and therefore get full access to it. If you encrypt the DB, if anyone can get access to your source code you're toast, since they will be able to see the DB user/passwords stored in the code. This issue persists if you use other SQL db's, but at least in those cases you can restrict the user supplied to the Access .accdb file to have certain permissions.
For my case, I have 3 levels of security. Firstly, I heavily restrict what I send out to make it very difficult to access the source code, which you kind of have to do no matter what. Secondly, I distribute different levels of access with different DB passwords (I'm using a MySQL back-end, you could do the same with a SQLServer back-end, but with Jet you're out of luck), so even if users could see the DB user and password, they are limited in what they can do. Thirdly, since I deploy on a corporate network, I take advantage of windows groups, and use those to filter out what is visible to different users. That way, users can only use the forms if they are authenticated onto our network. If the file discovers it's not on the network, it deletes itself and terminates.
Function IsMember(strDomain As String, strGroup _
As String, strMember As String) As Boolean
Dim grp As Object
Dim strpath As String
strpath = "WinNT://" & strDomain & "/"
Set grp = GetObject(strpath & strGroup & ",group")
IsMember = grp.IsMember(strpath & strMember)
End Function
Function GetCurrentUser() As String
GetCurrentUser = VBA.Environ$("USERNAME")
End Function
Function GetCurrentDomain() As String
GetCurrentDomain = VBA.Environ$("USERDOMAIN")
End Function
Client has asked me to create a self contained tool in MS Access, versions 2007 and 2016. It needs to be self contained because it will be copied to and from various laptops at various times. The tool may not create, delete, or modify any file except the accdb database itself. When the tool is in use, the user is unlikely to have network or internet access.
One of the criteria is the creation of new forms each time it is run. I realize that Access is meant to have all the forms and their controls already built before deployment, but client doesn't want that. I have solved that problem, creating x number of forms upon certain conditions, and creating 30-40 controls on each form based upon certain conditions, each with their own events, etc.
Now, how do I load his logo into a control on each form? Remember, the accdb must be self contained, so I can't count on the logo being in a certain directory or even on the machine in use, and I can't write it to the file system myself.
I can and have loaded the logo (jpeg) into one of my tables in an attachment field. It will be the only attachment in that field. It would be just as easy for it to be its own table, if that helps.
I can create attachment controls with VBA, but I don't know how to set the ControlSource to the FileData inside the attachment with VBA.
I also have had poor success attempting to embed the picture in an image control in a hidden form and setting the .picture property to the image name. It only seems to be working on my machine.
So, how do I display an attached jpeg on a newly created form?
Just asked and answered in SO access-vba. Here's one solution.
Saving Image as OLE Object, in Access
Many others on google and SO search
EDIT: You must read the whole question to see the author's answer
Answer:
So, what I ended up doing was following this
https://support.microsoft.com/en-us/kb/210486
I use the readBLOB function to read the file and save it into the
database. Then, when I run a report or open a form that has the
picture, onload, I use the WriteBlob function to write the file to a
temp folder and then use that path to populate an Image object.
I am working with Access 2003 and I need to change the filepath for a Query. I am working on a database that I did not create and basically my workflow is using Excel to populate a list (file names and info about photos)
Then I go back to Access and in Query's I have an option for "Append Results" which will update my database with my new information that has been loaded into Excel.
I get an error saying that the filepath is wrong. I know the correct filepath and this is a correct error, I just can't find where to update the query so I can change the filepath. I did a couple of googles and used microsoft help but figured it might be faster to ask in here.
Thank you,
JWV
It sounds like the workbook is linked to Access as a linked table. Sort your objects by type, and try and open each linked table until one fails. Then drop the link, and re-create it to the correct spreadsheet with the same table name.
To do this, you first backup the *.mdb (in case you get it wrong) and then just delete the link, like you would delete a table. Next you need to right Click on any table => Import Spreadsheet => Go to your spreadsheet and untick the box that says 'Import into database' (or something similar, I don't have access to Access (ha!) at the minute to test), this will give you a link to the spreadsheet, as opposed to actually copying it as a table, then rename it so it is the same name as the original link.
I guess as an alternative you could remap the drives so that, on machines where this needs to run, the old I: drive is mapped back to I:, and the same for H:.
Is there any way I can identify unused forms/reports/queries in a compiled Access (2003) project?
Edit : There is no check for unused objects menu item in my database window.
AccessContextMenu http://f.imagehost.org/0551/AcessContextMenu.jpg
Yes, in the Database window, right click on the object (form/report/etc) and select "Object Dependencies". If it doesn't show up any where, it probably isn't used.
Although that doesn't tell you if it is called in VBA code somewhere. However you can almost totally eliminate that possibility by doing a search for the object name when viewing the VBA and make sure that you have "Current Project" selected instead of "Current Module". It doesn't prevent some evil coder from string concatenating the object name together somewhere; but it's unlikely.
Try SpeedFerret over anything from fms (it has add'l features that will probably be useful to you as a developer, and it supports .mde files).
A demo can be obtained here:
http://www.moshannon.com/downloads.html
Other useful MSAccess utitlities:
http://www.granite.ab.ca/access/thirdparty.htm
I have a legacy app I am currently supporting that is having problems when people copy large quantities of data from a datasheet view.
The App is built in MS Access and the amount of rows being copied can get pretty large (sometimes in the thousands).
The funny thing about it is, you can paste the data out, but then Access keeps "rendering" the data into different formats and becomes CPU bound for LONG periods of time.
The Status message beside the progress bar at the bottom right of the MS Access Window is
Rendering Data to format: Biff5
Biff5 is a "Binary Interchange File Format (BIFF) version 5" According to Source
The app code doesn't use BIFF5 anywhere so I don't think this is an app problem.
I cannot find any data on this error anywhere on the web so I thought it would be a good question for stackoverflow.
So, can anyone help please?
Instead of trying to copy-paste, can't you just export the query to Excel?
I am not sure what the problem is but sometimes you can run into some very quirky bugs with Access. Have you tried running this on different machines? Different OS's? Would it be possible to paste the data into Excel and then import into Access using import functionality? Can you import the data directly instead of pasting it?
Try copy-paste operation through VBA:
Once user has selected data to copy, you can execute the code below when click on a button in the form, and then do a pastespecial in excel:
--- Data selected by user ---
RunCommand acCmdCopy
Dim xlApp As Object
Set xlApp = CreateObject(Class:="Excel.Application")
'New Excel Workbook
Dim xlWbook As Object 'Excel.Workbook
Set xlWbook = xlApp.Workbooks.Add
'Paste in excel
xlWSheet.Range("A1").Select
xlWSheet.PasteSpecial Link:=False, DisplayAsIcon:=False, Format:="Biff5"
We are all on the same OS here for this, I am investigating the possibility that some update sent out in the last maintenance window has caused this, as it wasn't a problem before this and there have been no new releases of the software in that time period.
Tried in on lot's of machines, same issue on them all.
The problem is actually with copying from a datasheet view in Access and pasting to Excel, not the other way around strangely.
Here is the use case
Access --> "Copy from datasheet"(Normal Ctrl+C) --> "paste into Excel" (Normal Ctrl+V)
(this works fine!)
When you then go back to Access to continue working, it is CPU bound doing the "Rendering Data to format: " thing, I mentioned above.
I'm stumped to be honest, it's all a bit strange.