Having trouble with buttons in mde file: list box .rowsource - sql

I have a form that has a list box and several buttons that run sqk statements for the list box.
sub on_onClick()
' error checking
me.listbox.rowsource = "SELECT tblMain.First, tblMain.last FROM tblMain ORDER BY tblMain.Last;"
so this kinda thing is what I use for the list box. it works fine for me in the .mdb, and after i have converted the database, split it, made the .mde I go into the mde and it works fine for me still. This is placed on a shared drive
HOWEVER, anyone else that tries to use this, none of the buttons are having an effect. Can't tell if they are not working, or the VBA is not returning any results for them. It works for me, but it is not working for them. So...this is for my local LAN team, I think they all have full control permissions??? The button clicks that get them to that form are working fine also.
please help!

A couple of things come to mind:
It is not clear from your question whether the mde file itself is on a shared drive or whether the back-end database is on the shared drive and each user has a copy of the mde file on their PC. If the users are using the same mde file on the network share then I would strongly suggest not taking this approach. (It probably isn't the cause of the issue, but it will get you into trouble down the road.) Give each user a copy of the mde (front end) and have the application point to the back-end database on the network share.
Make sure that the mde has the ability to relink the tables to the back-end mdb file.If you search SO you'll probably find examples of how to do this in code.
I suspect you may be running into an issue where the mde file is not able to find the back-end tables. In this case you won't receive an error message in your VBA code when you're setting the listbox's rowsource and it will appear as though nothing is happening.

Do they have Macro security disabled? By default, MAcro security is enabled in Access and none of your VBA code will run. To disable: open Access, Tools -> Macro -> Security and set to low.

I think it is generally best to use self-certified projects or a secure location rather than change security levels.
Some information on macro security:
Self Certify projects
General information on security principals for Office code and macro security
Trusted location defaults for Office 2003
Macro security in Office 2003

Related

What makes workbooks.cancheckout fail?

Here's the short version... let me know if any additional information can help.
I have an Excel document on SharePoint. I have two users who both are in the same security group and both have contribute access to the document.
On one user, workbooks.cancheckout("http://address/document") returns true as long as nobody else has it checked out. As designed.
With another user, workbooks.cancheckout("http://address/document") returns false. All the time.
The user CAN check the document out directly from SharePoint, so this is NOT a permissions issue. I believe it has something to do with the way Excel is trying to talk to SharePoint.
What causes "cancheckout" to return false, and does anyone have any suggestions on what is causing or how to fix this error?
The working user is using Office 2010. The broken one is 2013. However, several other users, all on 2013, are not having the error. OS is Windows 7 for all users.
I has similar issue. I asked user to manually access share point portal document from their desktop and then use excel VBA program. It works. if you change password then you have to manually go to share point and access that document so your credentials are stored somewhere in cache. It is wired but this is they way I resolved problem faced by one of my user.

Strange automation? error in Word2007

I'm pulling my hair out because I've run into the following problem with one of my clients:
My program uses extensive VBA automation in Word. Macros are saved in a specific Word template that is attached to each document. Some of the macros save the current document to a temporary folder under [User]/AppData/Roaming/... for further processing.
The client is using Win7 with Office2007 (Student edition). On the computer in question I keep getting an error with something like "No permission to save the file" (can't give exact error message because I've translated it from my language to English)
This happens when the macro tries to "SaveAs" the document.
The strange thing is that it happens only 8 out of 10 times - and not all the time. There are no special permissions set for the temporary folder I'm trying to save to.
I've tried changing Word security settings, tried adding the folder to the trusted folders list, tried using a different folder - to no avail.
The client's computer has Norton Antivirus (or Internet Security, I dunno) installed but temporary disabling it didn't solve the problem. (I know I should only be sure after a full uninstall but I can't do that on the client's comp)
Any help is appreciated!
Update: I've since found the exact error message in English: "Word cannot complete the save due to a file permission error."
I'm now looking on the web for similar forum posts but if you guys know something, please let me know. Thanks!
Is an antivirus or similar program running? On my development computers many similar problems went away when I changed from (vendor "X" security bundle) to ESET.

Access 2007, VBA, a tiny project for a school, and the Trust Center

A friend asked for my help putting together an Access database for a small department at a university. It tracks medical info on some animals. The problem is that to make the application easy enough to use, we had to write some VBA code to glue different forms together. When we open the database (or a new, updated version of the database), we get the little VBA Macro Trust thingie, and we're having a hard time figuring out how to get rid of that warning. I'm an open-source developer and my organization's sysadmin, so it's usually not a problem for me to sign rpm packages with the CA Cert I maintain...
My friend's department uses Windows PCs with Novell, but their computer support department has stated that they don't provide any support for user-created applications (i.e. providing a certificate signed by the departmental CA) nor will they provide administrator access to the computers so that we can change the trust settings. They also don't have the skills or expertise to code the application for the users. (Thanks, chaps, mighty helpful.)
Additionally, in our entire University, users are explicitly instructed not to ever, ever click a 'yes, I trust this' button. Re-educating users for the sake of this little access database that she's put together is a problem, since about 20 people will be using it to look up information.
Since I'm helping her, my inclination would be to do it in C# with a embedded database file stored on a shared drive, but that also falls under "user created applications" and I wouldn't be able to run an installer since no one has administrative rights.
Is there any way to work around the need to bypass the trust setting for macros every time someone opens this file? I thought that if we didn't use macros at all and just used VBA it would work, but that's apparently not the case.
You might find some help on:
http://msdn.microsoft.com/en-us/library/bb421308.aspx#OfficeAccess2007SecurityConsiderations_EnablingExecutableContentDatabases
Specifically:
Embedded Access Macros
In Office Access 2007, you can now
embed macros in form events like VBA
instead of saving them in the Macro
collection as separate entities. This
makes them more portable because you
can copy and paste a control with an
embedded macro, and the macro remains
with the control. In many cases, an
embedded macro for opening a report is
sufficient instead of a short sequence
of VBA for the same task. You can see
many samples of these embedded macros
in the Featured Online Database
Templates in the Getting Started with
Access pane that appears if you open
Access 2007 without selecting a
database. Because most Access macros
are not executable content, they are
an important tool when you have to
make your databases work in all
circumstances.
You're clearly on the right track since you mention the TRUST CENTER. I don't use A2007, but 2 minutes of Googling turned up these two articles:
View my options and settings in the Trust Center
Create, remove, or change a trusted location for your files
The instructions given there for Access are:
Click the Microsoft Office Button , and then click Access Options.
Click Trust Center, click Trust Center Settings, and then click Trusted Locations.
If you want to create a trusted location that is not local to your computer, select the Allow trusted locations on my network (not recommended) check box.
Click Add new location.
In the Path box, type the name of the folder that you want to use as a trusted location, or click Browse to locate the folder.
If you want to include subfolders as trusted locations, select the Subfolders of this location are also trusted check box.
In the Description box, type what you want to describe the purpose of the trusted location.
Click OK.
Looks to me like that should take care of your problems, though it has to be done on each users computer.

Insufficient memory to continue the execution of the program

My Application (Vb.net, Access 2003/2007) is to scan Access Database files for activex controls and to generate report accordingly.
Problem:
Getting an error like:
"Insufficient memory to continue the execution of the program."
The above error occurs while scanning for older version of Access files like prior to office 2000.
And the line of code where I get this is as follows:
Dim oForm As Access.Form
Dim oAccess as Access.Application
oForm = oAccess.Forms(objForms.Name)
But it opens the file and form as well.
Need Help:
Whether it is possible to read the file (Access Forms and Reports) or not?
Please provide me reference or any solution.
You appear to doing COM automation of Access to open the forms and then cycle through their controls looking for certain properties.
Another solution would also involve automating Access, but it wouldn't require actually opening the form, and that's the undocumented Application.SaveAsText command. You'd do something like this:
Application.Saveastext acForm, "dlgWebBrowser", _
"C:\Output\dlgWebBrowser.txt"
You would then have to figure out how ActiveX controls are described in that file. If that file looks like the code for a VB form, that's because that's precisely what it is.
The example above had an IE web browser control on it, and after a dump of OLE data, it had this in it:
OLEClass ="Microsoft Web Browser"
Class ="Shell.Explorer.2"
GUID = Begin
0x54c1ea41936d2046b9dc5b29905976e3
End
I would expect that all ActiveX controls will have an OLEClass, but I non-native avoid ActiveX controls on principle because of the problems they can cause if not properly installed when you try to run the app.
In fact, that could be the source of the problem -- if you open the Access form on a machine that doesn't have the relevant ActiveX control registered, it's going to fail, and the form won't open.
My bet is that Application.SaveAsText is going to sidestep that problem entirely, since the form doesn't have to be opened.
I've seen behaviour very similar to this before. Access 97 files will sometimes report an 'out of memory' error if you try to open them on a computer with more than (I think) 1Gb of RAM. The error doesn't always manifest itself immediately - sometimes the project can appear to run normally but crash when you try to open a particularly large object.
In the case where we did run into this the users were running an old Access 97 database on new XP machines they'd been upgraded to with modern amounts of RAM. Tech support for the company tried everything they could think of - including complete office reinstalls, applying all patches etc. but eventually had to resort to removing RAM from the computers - whereupon the errors went away and everything was rock solid again. I am uncertain as to the exact cause, but it will be connected with memory management in the Access 97 file format (I believe the error is on MSDN somewhere but I wasn't directly involved with Tech support hunting the solution down - I'd just written the application many years before)
I'd suggest you're only way out is to use a special, low memory, PC to run the application.

Lock Excel Document after a certain Date

How can I cripple an excel document after a certain date? I want it to become unusable after, say, 12/31/2009.
I was thinking about putting one of those Must Enable Macros things in there that hides all the sheets on close and leaves one tab that says you must enable macros. Then having an on open macro that unhides all those tabs, but also will close itself if after a certain date. This has a few drawbacks in that someone could just enter in the macro code (without macros enabled) and change the expiration date... or even just change their system time. Any thoughts about good ways to do it? Is my method pretty much as good as you can get? or are there better ways out there?
Thanks.
You might want to have a look at Microsoft's Information Rights Management (IRM) technology. IRM lets you control which users are permitted to read, edit, print etc the content of a document. It is also possible to specify an expiration date.
IRM requires you to either have an ActiveDirectory infrastructure with a domain controller or you may use the IRM service hosted by Microsoft.
For further details check out Controlling workbook access in Excel with Information Rights Management.
Dan, I am not sure of the purpose you are trying to lock the excel sheet. However if you write the macro then you can password protect the VBA code so that no changes are made to the code.
Having said so, there is still a possibility to have workarounds and access the excel file; no method can be foolproof.
Cheers...