I had been told that if I open Access 97, the whole system or at least most of it are inside some database. Is it true? For example if I write some VB code into it, the whole code is inside some database. I thought before that only the data I fetch from SQL are inside some database.
The "whole system" is inside Access, so if you have forms and such they're mingled in that file along with the data.
Access keeps everything in an .mdb file. When you open up the project you will see your tabs (tables, queries, forms, etc. etc. etc.) Code in Modules is there as are Macros.
It actually keeps a lot more in this file that is generally hidden - basically its meta data for the project. If you go to tools -> options you should see a check box for system objects. Select that and when you look at tables you will see names like this:
MSysACEs
MSysModules
MSysModules2
MSysObjects
MSysQueries
MSysRelationships
You play with these tables at your own risk.
The only other thing that is not stored in the main file is security info - if you try to lock down the file. That is in a system.mdw file See here for more http://support.microsoft.com/kb/303941/EN-US. I have only used this or seen it used when we wanted to lock down an 'application'.
Related
I have an access database that I have been using for a while. I have been meaning to split the database for a while but hesitant to. I have many forms that link to tables. VBA code that aid in the forms and creating reports from this access database. Sometimes the VBA code will have a dynamic query that changes on certain conditions and runs a DoCmd.RunSQL.
If I split the database will all my VBA code break down as it points to the tables within my database. Do they need to be pointed to the backend or pointing towards the linked table is enough. Will the split handle this by itself?
Let me know If I was clear enough. My main concern is my forms/VBA code will stop working.
Make a backup, go to meny Database Tools, locate the Split database wizard.
Run this, and you are done.
I have a MS Access 2013 file that I am using. There are two possibly related concerns. For some context, this is an MS Access 2013 file with some forms and some tables and a bit of VBA for the logic of how those two interact. For versioning, the file has been copied and pasted with a datestamp on it for the newer version.
The first concern is that all the file sizes for the various files is exactly the same, even though data has been added and some changes to the forms were made.
The second concern is that when I right click on a table and go to table properties, it says "Shortcut to Table (Local): table_name" where table_name is the name of the table. It appears that this is a shortcut to a table somewhere, but I'm not sure where. The forms are also shortcuts to forms, but I don't see the destination form in my file anywhere, even after unhiding system objects. My questions regarding this are: how did this happen (I was assuming it had something to do with the fact that I copied and pasted the file) and where is the file that these are a shortcut to?
Everything seems to work fine, but I'm concerned that if one of the legacy files gets removed that I might lose some data. Is my data being stored within this file, or did it get split somehow and the data is being stored in a different file somewhere? I just want to have a better grasp of what exactly is going on.
I feel like I have a good handle on the SQL and a pretty good grasp of the VBA, but the MS Access specific nuances are something I'm still gaining familiarity with.
Well, it seems it was as simple as changing the view in your navigation pane to something else than custom!
I am completely perplexed.
A colleague's got a database issue. I noticed that the (internal) software that created the local database file with the problem, uses programmatic access to MS JET, which meant an easy first step was to see if MS Access (2010) was happy with the database - and then fix, export/import or repair, as a first step.
I copied the stand-alone local Jet data file to a non-networked virtual machine (so no chance of external data), and MS Access opened the db file easily, but I can't make sense of what I'm seeing.
MS Access is configured on that system to show all hidden and system objects, confirmed since the Access system tables in the file are all visible and can be opened. These are my observations:
The object browser lists the usual MS system tables, and a bunch of SELECT queries (which look correct) of the form SELECT (FIELD LIST) FROM (OTHERTABLENAME) WHERE (FIELDNAME=VALUE), nothing more.
The select queries show the usual grid with valid data records when opened, and the data looks correct as well.
No data tables with the given names are showing in the object browser interface.
The given names are listed as objects of the database, in the system table MSysObjects.
So..... the underlying data tables ARE named in MSysObjects, and seem to be true data tables... but they are NOT being listed in the object browser and I can't figure how to open their datasheets (although MS Access' system tables are, and "Show hidden/system" are both enabled)... and the tables surely do exist in the file since an apparent SELECT query is pulling their data from them, and the file is on a clean non-networked machine with no other sources reachable.
Any ideas? I want to check the underlying data but ... whats going on?
When I examined your database, I discovered the reason you can't access the tables normally is because the authors of the internal application which created the db file implemented measures to prevent normal access.
I advise you to contact them and your managers to get authorization and assistance to view the data.
Also, please be cautious with this question. A suspicious person might uncharitably interpret your question as a disguised request for hacking help. Please note I am not accusing you of anything underhanded ... simply asking you to notice how your question might be perceived. And, if that were to happen, I don't know what the consequences would be on Stack Overflow, but I can't imagine it would be good. So please be careful.
I split my DB and now when I try to change some information on a few queries, I can't access them. I have a front end and a back end and understand that I should make changes to queries/forms via the front end, but they are grayed out and inaccessible.
At this point, I tried unsplitting the DB (which I believe I did), but I still can't edit those queries or forms.
I can click on the query/form and see the result of it, but I can't get to design view to edit it.
I'm taking a shot in the dark and saying that in the process of splitting your database, you either created your front-end in an accdr or accde format (a runtime application). The purpose of this is that you shouldn't be able to open queries or forms or tables in design view on the front end. You can just open your database and save it again as an accdb file and continue as normal.
If you're having other problems with the linked tables, I suggest you open the Linked Table Manager and refresh the links (if you moved the backend file, this is necessary).
I would recommend trying to proceed as normal by using Shift Bypass just to be sure. ( Hold the shift key when you start the database. Then attempt to modify in design view).
If these fail, I would attempt to copy the queries and /or forms if possible and create new ones.
I have an Access 2003 database using MS-JET linked tables (that is, there are two *.mdb files). The overall task is to move to SQL server. However the existing databases have multiple fields with spaces and other characters that upset both of the Access migration wizards. So the intermediate task is to make a version of the existing mdb's with updated field names.
"Simply" changing field names in the UI mdb file doesn't work, because of the linked tables being read-only in that mdb. Updating the Data mdb file field names first doesn't work because the UI mdb then throws a wobbly on startup and Access gives up.
I'm looking for suggestions, but options I can see are:
re-integrate the Data mdb back into the UI one, do the updates, then re-export the data. Seems very risky to me (system is live, don't want to play with data any more than strictly necessary).
I've looked at several answers here relating to changing ODBC details with VBA code, which is interesting, and I can see how I might be able to programmatically edit the linked tables' names. Is this going to work? Is there a better way?
Unlink all linked tables, then edit in UI mdb the remaining forms, reports, queries (but would that work??) and edit the Data mdb fields, and finally relink everything. Will it fall apart?? ... seems likely.
Any suggestions?
Ruth
I go through this process every time I take over an existing Access application -- I have to bring it up to my own standards for naming conventions before I do anything significant with it. Recently I built a quick-and-dirty utility to rename fields. It was made for me and has very little error recovery, and a UI that is ugly, but it might be faster than doing it yourself.
See what track name autocorrect offers. How Name AutoCorrect Works in Microsoft Access
Make a copy of your UI MDB, delete the linked tables, then import them (as tables rather than links) from the Data MDB. Once you enable autocorrect, Access will attempt to propagate your field name changes wherever they are used (in forms for example). Unlikely it will catch 100% of the necessary changes, but it should resolve a big chunk of them. You would then need to manually track down and fix the rest.
Once you have everything fixed, you could use that MDB version to "upsize" your tables to SQL Server. However, one huge complication is if the original database is "live" while you're making changes to the new version. If you absolutely can't take the database out of service in the interim, you could discard the data from the new tables, then use "append" queries which alias the old to new field names to pull in the latest data.
INSERT INTO NewTable (emp_id, another_field)
SELECT
[emp ID],
[another field]
FROM OldTable IN 'C:\somefolder\Data.mdb';
Finally, a warning about autocorrect: do not leave it enabled in the production version of your database because strange things can happen. The safest approach IMO is to turn it on, complete your object name changes, then turn it back off again.
You might find Rick Fisher's Find and Replace tool helpful if you need to propagate name changes through the project. I've relied on it for years (though I don't do much Access development lately): http://www.rickworld.com/products.html
I think this tool will change the names of tables and fields for you but I am not sure. I mostly used it for finding references to tables and queries in other queries, form and report properties, and VBA code.