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.
Related
I am aware of MS Access - link to query in another Access database from a number to years back. My need is not so simple.
We have a number of MS Access ACCDBs which use linked tables to perform certain activities on linked tables (in both SQL Server DBs and local MDBs/ACCDBs). They consist of a very large number of queries and macros etc.
Each ACCDB references the main database using the linked tables and we have a small number of such databases with different content but identical structure. In the past, we have used some VBA code to re-link the main database. But the content is now significantly different in the main databases that we'd like to create a separate ACCDB for each content type. Naturally, because they are dealing with identical structures, a significant (>75%) portion of the objects (queries, macros, tables etc.) are notionally identical. Is there any way to create a "container" for the common stuff - similar to an ACCDE to hold the common stuff and reduce the maintenance burden as the common stuff "evolves" in one ACCDB (and needs to be distributed to the other ACCDB)?
We use the full range of Access objects - including all "action" query types, macros, linked tables etc.
The referenced link only allows selection queries. It doesn't seem as though "action" queries and macros can use the same kind of syntax to access the items in the external DB.
TIA,
Paolo
[Edit: To be clear, I need to run the stuff in the "library" DB in the context of the main ACCDB. Thus if I have a query "Select * from myTable" stored in the Library DB when I run it, it needs to reference the myTable in the ACCDB not the one in the library (if I even need one there)]
You can add a reference to a "library" database, and that will give you direct access to the code in that database.
To access queries, you can open the external database, but queries will run in their external context, not in the current (local) database. However, the tables you have linked in the current database can be linked as well in the external database. This way it doesn't matter where the query runs.
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 am starting to create an MSAccess database, I have no Access experience - my previous experience is with MySQL and Oracle. Initially I had some difficulty coming to terms with the fact that MSAccess usually stores both the front end application and the Jet Engine database in the same file. It's different from what I'm used to. Plus the database will be shared over a network, and it just makes more sense to split the application from the data.
After some reading, I see that it is possible to store data in one file, and then link to the application elements in another file. Every article I've come across for this deals with splitting the database into two parts, after the database has already been made, and never discusses creating split database applications from the start. Is it because that would be a bad idea? I can't really imagine why, except that I've noticed that Access does not let me keep two database files open at the same time (it automatically closes one). So I am foreseeing a need to constantly to open and re-open files if I go down that route.
There is one practical reason why you might want to start with a single database. If you start with a front and back end file, you'll have to create tables in one database, then set up the link for each table manually.
This is not a big deal, but if you're just starting the system, you can save some busywork by developing the pilot system in one file, then splitting it. My assumption is you'll probably be making a lot of changes to the data structure at the outset; your work will go smoother if you're working in one file.
It is definitely a good idea to split the database before you deploy it to production. I'm not sure why you're having problems opening 2 Access files at once; this is not a restriction of Access.
You can create the two db files separately at the outset. I do that often. I seldom need both open at the same time in the Access interface. I only open the back-end database, which houses the tables, indexes, and relationships, to modify the design of those db objects. And those types of changes are relatively infrequent; most of the development workload is for the front-end db. To modify data in the tables, you can use the table links from the front-end db.
It is not a bad idea. You can have two files open at the same time, either open another Access instance or launch by double-clicking the second file. Make sure you have created a suitable back-end design before you start on the front-end.
It is more efficient to have it all in one file while you're alone to work on it. Once the database design is finalised, then you can split the db.
Splitting the db is usefull during testing as well: it allows you to reset your data to a known state in about 5 sec, just by copying a saved version of the back-end.
Good Morning,
I've been asked to make changes to a custom CMS, involving the addition and deletion of form fields and corresponding database fields. The UI changes are pretty basic. However, the twist is that I don't have direct access to the MySQL database. I've only been given a .sql file. I've edited it, changing the table structures to accomodate the UI modifications. Besides the table edits in the .sql file, is there anything else I should do to it to ensure that it re-creates the database correctly?
Thanks,
Sid
is there anything else I should do to
it to ensure that it re-creates the
database correctly?
Can you request a copy of the database, or the database with dummy data, or even a script that creates the database? That way, you can take this home, and then double check your SQL file does the right thing.
I'm trying to split a database into two pieces -- a backend that updates automatically, and a front-end that allows searching and adding/editing comments. The data in the source database is pulled together from multiple tables into a pair of queries, and I want to use these queries as the source of the current database.
Access 2007 supports splitting a database into multiple pieces, but not in the way I'm looking for. It keeps the tables in the source database and puts all the forms, queries, reports, and macros into the new database. The tables and queries are already in the back-end, and this new database should just provide a good GUI to the end-user.
Access 2007 also supports linked tables, but these can only use a table as a source, not a query object.
I was thinking that the best way to do this would be to do a SQL query along the lines of
SELECT * FROM SourceQuery IN "C:\Path\To\ExternalDB.accdb";
Is what I'm working towards even possible, and would this be the best way to do it?
Since its still relatively early in the project, rearchitecting the database isn't out of the question, but is something I'd prefer to avoid.
You described the usual Access BE-FE division correctly: only tables in the back-end. I'm aware not all DB programs do it that way, but this is Access and my approach would be to honor the usual division. (And you hardly have a choice in that you can't "link to a query" in Access.)
Reviewing your comment ('There is a specific reason ...'), I think this would possibly mean
adding a few more tables to the back-end, essentially buckets (import-data in ready form; export 1; export 2) that allow all users to get to consistent processed data;
making a small admin FE that sits next to the BE and stores your modules, queries for export, and export routines; and
having some redundant queries on the user FE. This is vexing in my own work. I just try to design sturdy stable "building block" queries in those roles, and keep their number to a minimum.
Hope I'm understanding you correctly, but the most sensible solution would be to link the tables in the backend DB and copy the queries to the UI database. Those queries would still be able to access the uderlying tables (via the linked tables) without issues and would be accessible through normal means to your forms and VBA code.
Is there a particular reason you don't want the queries in the UI database?