Changes in accde not reflecting in source

[HiTechCoach]

Typically you would not create an accde until the very end of development and testing.
The steps are conceptual design, development, split database, test, review, accept for "production",
--then -- make a backup of your FE and BE. Create an accde from your FE for distribution.

I do not like the older waterfall method of "conceptual design, development, split database, test, review, accept for production". I believe it leads to lower quality software because issues are not caught until late in the development and are too costly and time consuming to fix.

For 25+ years now I have followed a method that today is referred to as Agile. I use this method for many different development platforms. You have an application (front end) and data (back end). With Access I split every database from the start. Backup the database every time before I open them for editing. Test often with a back end that has several years worth of data. Create a mde/accde at least every week for testing and review.

Splitting from the start also makes it easy to copy the application (front end) and experiment.

Your backup of the FE from which you create the accde is absolutely necessary. Guard it as gold. You must work with the accdb version when you modify anything in your front end. After you have made modifications to the FE (accdb), BACK IT UP!, then make an accde from a copy

That is great advice. The .accdb front end is your master source. Make lots of backups! I make a backup every time before I open a .mdb or accdb.

[jobbie]

I would import the tables into a new blank database and treat that as the backend. If you have a copy of the accdb that you used to create the accde, use a copy of that to link to your new backend. With this new accdb frontend, create an accde and provide it to the User. Your new accdb can be edited and then used to create new versions of the accde.

I use special folders to store copies that are archived, master accde, accdb used for revisions, etc.

Thanks I finally got time to follow your instructions. It seems to have solved the issue. I just want to make sure that I don't need to split the db anymore as I have already imported the tables to a new db and linked it to a copy of my original accdb?

One more thing should I also import the queries or just the tables? If I were to import the queries how would I modify them in the future?

[ItsMe]

You should not need anything other than tables in the backend file. Queries, forms, reports, etc. go in the frontend file. There are always exceptions, but the only thing you need in the backend is the actual data.

[jobbie]

You should not need anything other than tables in the backend file. Queries, forms, reports, etc. go in the frontend file. There are always exceptions, but the only thing you need in the backend is the actual data.

So how do I hide my queries?

[orange]

jobbie,
I think you should do some research on MSAccess split data base.
This might help put things into context.
And this may help with the ACCDE

[ItsMe]

It is not easy. The first thing you need to do is determine how difficult you need to make it for the User to access restricted areas of your application. I use several techniques. The first thing you need to do is use several copies of the frontend file when preparing for distribution of your FE file.

You might want to start by going to options and hiding the Navigation Pane. However, keeping the Users out of Options requires hiding the Ribbon or customizing the Ribbon.

Another approach might be to use code to hide each query object. So you might loop through a table's records where each name of each object you want to hide is stored.

Here is one untested example I found on the internet. Instead, I would probably iterate all of the table objects and query objects using DAO and TableDefs/QueryDefs.

Application.SetHiddenAttribute acTable, "MyTable", True