I have recently taken a job that involves using an Access database to find information. The database in question was built by a developer who left before it was completed. He also didn't leave any documentation behind.
The database uses queries, forms, and VBA. Some of the queries are no longer valid since the source data has a different format than what it was when the database was developed. I know SQL and some basic VBA so I'm trying to modify the SQL; however, I cannot view the SQL behind the queries. I can't open it in Design View or SQL View. I can't even right-click on any object. Not only that but when I open an object, I can't right click on the top tab to close it. There's a red x that populates on the top-right that I have to use. I've tried holding shift when opening the DB, but it still happens. I also went to: menu option Tools -> Startup -> to see if 'Allow Default ShortCut Menus' was unchecked; however, it wasn't. I've checked other forums but haven't been able to find a solution. I think it may be in the VBA somewhere but there are tons of modules and each module has a boat-load of sub procedures in it. I have no idea what else it could be. Any and all insight would be greatly appreciated!
#Andre and #Comintern both provided correct answers. The culprit was in the Auto Exec function and it had a loop that went through each CommandBar and set Enabled = False.
Related
I made a database with access, and I created dataentryform and inside it there are some subforms (I have related tables), I used query to provive these subform and without these qaueries I cannot enter data into subforms (if I delete these queries then when I open main form I see blank rectangular inside myform instead of them.
enter image description hereIs there any possible way to lock query and also subform in navigation pane?
In general, as long as the user is running an application on his own PC, you cannot prevent him from deliberately modifying/breaking it. This is true for all applications, not only MS-Access-based ones.
That said, there are some ways to make it harder to accidentally modify it:
The recommended way is to start Access in "runtime mode", either by specifying the /runtime flag on the command line or by renaming your accdb/accde to accdr. That way, the user won't have a navigation pane and can only interact with the application through the ways that you, as the developer, explicitly provide.
You can use user-level security to "lock" your queries. However, user-level security was deprecated with Access 2007. It can only be used with the old, legacy mdb format (rather than the new accdb format) and should not be used for new projects.
Right now I'm working on an application in access 2010 that generates letters based of data taken from a share point site. The user inputs some parameters from some combo boxes on a form. After the selection is made the user selects the type of letter they want by pressing a button.
This works fine but I'm experiencing an odd issue when I close access and reopen it later.
When I open the form after starting access again I'll attempt to create a letter but instead of working like it did before the criteria prompt window appears asking for a parameter instead of taking the form values.
This happens every-time I restart access and the way I've been fixing it is by changing the names of the combo-boxes and then adjusting the queries accordingly.
This is what i was using to get the form values in the query
Like [Forms]![Main Menu]![A] & "*" (A is the name of the combo box, I got tired of renaming it)
Any Idea whats going on because I'm at a loss.
Thanks in advance!
If you are 100% positive that Access is finding your parameters just fine, and when Access closes they are lost, then:
Do you have any backup copies of this database before the error
occurred? Can you use one of them?
Do you Compact & Repair the database every time you close it? This
can be used somewhat as "damage control," because MS Access does
have a tendency to become corrupt.
Make sure the Main Menu form is open as long as the query is
running. Does it close right away (aka the query isn't finding the
parameter because the form is closed)?
From searching around, it seems that you aren't the only person with this problem. A known fix for people seems to have been copying all objects into a new database (which to me, sounds like the database is corrupt.) This could also mean maybe only your form is corrupt. Perhaps try to create a new form that does all of the same things that your Main Menu form does.
I'm sorry there doesn't seem to be a 'clear-cut' definitive solution for your situation.
If any VBA is involved, see below:
If you use the "Database Documenter" feature and check "yes" to all the options, you will obtain an exhaustive report that should let you trap your problem parameter. Export this report as an .rtf or .pdf document, so it is searchable. Identify a keyword from the dialog prompt, and search on that.
Once you check the query objects using the Documenter, check your VBA code. You'll do this by stepping through code in the IDE. If the main form has subforms, they are opened with (within) the main form. And they load before the main form.
Identify those subforms.
Sprinkle breakpoints in their code modules (if you find a Load function, that is highly relevant).
If the main form has a code module, do the same there.
From this thread
I have a MDB database with plenty of VBA code, there are also connection strings to database. I need to have both the connection strings hidden, and the VBA code unavailable. In general I need to disable all functionality that is granted through shift-clicking the database file.
I tried making an MDE but it seemed to have no actual impact even though no errors were thrown, the MDE is exactly as accessible.
Thanks!
In addition to creating an MDE, you can:
disable shift-clicking
hide the database window
(this link shows how to do it manually in the options - it's also possible with VBA, but I can't find an example right now. I can look tomorrow if you're interested)
At work, we have a "publish" process where we create an MDE and do the things linked above.
EDIT:
Creating an MDE is a realistic way to prevent access to the VBA code - MDEs contain no code and you can't edit forms and reports.
The only thing you can do in an MDE is opening the database window and view/edit the tables. But you can kind of prevent that by disabling shift-clicking and hiding the database window (see my links above).
Note that it's still possible to link the tables in another MS Access database and view/edit them. So there's no 100% proof way to secure anything that you put into a table.
But when you put the connection strings into the VBA code and completely remove the code by creating an MDE, it's not possible to get the connection string out of the MDE.
Been struggling with this for quite some time so any help is appreciated. Spent a lot of time looking over MSDN, Google, etc, and still no luck.
I have an SSIS project I intent to always execute from within BID. The project has multiple packages, so I created a Data Source to share amongst all the packages.
In each package, I create a Connection Manager based of that Data Source. Now when I go and edit this Data Source's connection string to point to a different server, the change is NOT reflected in the packages.
Now, MSDN says the opposite. In fact, one of the main purposes of Data Sources is to update connection strings easily from within BID; at least according to MSDN.
And for me its not working. This has got to be the most annoying thing I have seen thus far in BID.
Any one have any suggestions?
UPDATE
It looks like BID does not synchronize a Data Source change with Connection Managers if the data source's authentication is SQL server. If it is Windows authentication, it detects the change fine.
Very interesting indeed.
Just a guess. This kind of behavior happens when you have a "package configuration" configured.
Right click on any blank area of your control flow and select "package configuration". If the "Enable package configurations" check box is selected and you have a configuration on your connection string, it will override any value you had specified manually.
I figured it out for those that are interested. I am not sure if this is a bug in BID or not but I hope this helps someone else struggling with this problem.
All you have to do is simply open up all your packages at one time. This is as simple as highlighting all the packages in the solution, right clicking, and choose "open".
Once all the packages have been opened, go ahead and edit your Data Source's connection properties. BID will automatically apply the new changes to all the open packages that have a connection manager based on that Data source.
Hope this helps someone.
I found I could not change any of the data connection configuration values because there was a variable defined for the connection string. Enabling/disabling package configurations had no effect on the behavior.
To access the variables menu, right click anywhere on the DTSX designer background and select Variables. Make sure you do not have any values in the variables list that are being referenced by your data connection. If you can not find the references anywhere, try fixing the values for the variables that might be affecting it.
You need to change in respective dtsx package. Open it in notepad++ and search for the connection string, modify it and save it. You can see the connection change in solution now.
I'm using the Access Developer Extensions to attempt to source control this access database in TFS, however, I'm not sure I am doing it right. I can add a .mdb to source control and create a database from that source control.
I'm probably making a stupid mistake, but I can't figure out how to close the database I created from source control and reopen it while it's still under source.
Does anyone know of any tips or guides on this? I've searched for help on Access Developer Extentsions but I haven't found much. Thanks in advance guys!
I think I found what I was doing wrong. My database automatically compacts on close, so when it tried to do this Access asked me if I wanted "to remove the compacted database from source control". I thought this meant it would just not store the .mdb file, but still keep the objects (like tables, vba, queries, forms, etc) under source. However, this appears to completely remove it... from MSDN:
"Changes to Microsoft Access Behavior
Using the Compact Database Command
In order to take a database that is under source code control and deliver it to a user, you need a way to cut the database's ties to source code control. When you compact a database that is under source code control, Microsoft Access 2000 prompts you to remove the database from source code control.
To remove the database from source code control, Microsoft Access simply removes the Visual SourceSafe properties from the Microsoft Access database and its objects."
http://msdn.microsoft.com/en-us/library/aa155494(v=office.10).aspx
When I said do not remove compacted database from source control, my database and it's objects stayed under source.