I have no idea what you mean by PassBse. Is that your .accde file?
How are you going to keep the tables but also copy them? To where?

Have you tried the Importing feature under External Data > New Data Source > From Database > Access?
You can import tables or the "software" objects.
I'm not sure if you can do that in a VBA procedure, maybe Richard or someone else knows?

Or maybe you are looking for something like this?
https://chatgpt.com/share/679ac5e0-7fb8-800e-81d9-af61c4161352

Thomas,  PassBase is my software I am developing.  That is the ACCDE file.  You suggestion of using External Data> New Source>From Database>access.

Will not work.  My customers or users will not have access to this.  The software is canned.  I have to have it copy the table.  tied into the update.

Maybe the Install package you suggested will do this.  I have not purchased it yet.  

The chatgpt might work.  I would have to put the code inside the install program.  Looks like I have do some more research.

Thank you, Thomas.

I went to sse website and viewing the tutorials.  I will pose my question to SSE.

The most critical issue is that I need to preserve the data the customer or user created.  In yet I need the user to access the data.  Its their data in those tables.  I will also asking SSE if they put there software on sale.  Reduced from $190.00.  I will report back on these two issues.

@Jeff, I see, you don't want an "administrator" to deploy your db. Kinda makes sense if it's a one-up sale. But why not split the database into the same folder, and then just pass along a new .accde (that I presume only you are allowed to create)? Then users truly "own" the data and your hands are clean of any mishaps outside your .accde.

I didn't mention SSE, and don't know what it is.

I have questions about the ChatGPT code, especially if using relationships. It's worth a test I suppose, but for me it has to be another day. I hope you report back your experience with it.

I am still waiting on an answer from SSE software. I recently watched a video on splitting the database.  That idea is feasible.  More  research needed.  there is liability concerning their data.  That's why I am investigating and going to test it numerous times on a another laptop.

@ Jeff, I've played with splitting and I've had no problems with the BE being local or remote.
The only problem I've run across so far is when the table design changes.
I haven't found a programmatic way to modify the table design.
I'm just starting to tighten up the relationships with cascading updates.
I know I'll need to test how that all works with a BE, if the FE makes error inducing changes that violate the relationship rules.
Maybe Richard has videos on these issues?

No response from SSE.  I sent it Thursday.  I will look else where.  Very disappointed in this company.

I'm confused, so PassBase is your software that you're building in Microsoft Access, and it has a front end and a back end. You want to be able to add features to it and just give the users the update so they can keep their existing back end. That's fine; that's just typically how an Access database works. They'll just have to relink their tables in your front end because everybody's folder structure is different unless you make them sign up or set up the database in the same folder like a Z:\ drive, so everyone's got the same drive mappings. I've done that with clients before. I made all my clients use Z:\ drive, so I didn't have to remap their tables with every new front end. I do have lessons on if you want to remap the front end to new back end tables. But who is SSE, and exactly why do you need them? I'm very confused with what you've got going on here in this thread.

@Richard, I think Jeff had an integrated design, and at first he wanted to be able to update the software in only one .accde file, leaving the existing tables alone.
I think he was starting to come around to the idea of splitting the database.
Importing wasn't an option for an .accde file and I'm guessing that one can't export forms, queries, reports and modules to a .accde from an .accdb (I've never tried).

No, you cannot. In fact, the first version of my Access Updater, that's what I tried doing - just posting the changed components and letting the front end pull in a changed form or report. But that's just not possible, so I had to revert to replacing the entire ACCDE front end file.

I haven't seen the Access Updater. I'm guessing Jeff could use that. My next big project may be to take that idea to the next level.

I complained earlier that instancing has some serious problems, one of them being the cross contamination in module and private variables when the same form or report is run twice in one .accde or .accdb. The only way I see around that is to "instance" a whole new Access executable to preserve internal Access variable tables.

Which means some sort of Access db to spawn the Front End that first asks for which client. Then it copies and creates a new run of a "template" Front End.  The spawn program can check if a newer version is available in the Back End ACE.

Richard Yes PassBase is my software design.  It is not a networked software.  SSE is a installer package.  It takes PassBase and installs it in a specific drive.

My question is when it comes to update ACCDE file.  Will it still read and write to the data files.  I need those untouched.  they belong to the user or customer.

I think the best way to handle it is to split the database.  this separates the forms, Queries, and Reports from the tables.  I will try this using  a second laptop.  Its all got to be tested.

Jeff

If you want to distribute an updated database to your users, and you don't want to mess with their data, then you have two options:

1. Split the database (recommended). This way you only have to replace YOUR front-end file.

2. Have them EXPORT their data to a temp file, give them a new database, have them IMPORT their data back in. This is a pain.

Split database wins almost every time.

You'll probably need to relink the tables: Relink Tables

I agree splitting the database wins hands down.  Option two means more coding. Therefore option #1 wins.

thank you Thomas and Richard for responding. this has been an issue.  Which I knew at some point I needed to address.

SSE is a installer package.  I am going to find another way to install it on a single user computer or laptop.  No networking.

Any suggestions are encouraged.

@Jeff, I'm not sure why you need an installer package. I zip up my ADS .accde demo, and people can unzip to any folder they like, and it works. For the demo I don't split, but I can't see why it wouldn't work with an unzip, since I would put it in the same folder.  I'm guessing, you're not doing anything with the registry or installing DLL files?

Yes, users have to know how to unzip, set trusted locations (does SSE do that?), but I walk them through the steps in a video:

https://youtu.be/9v4nvbGhD5E?si=z2R3A8fifvsJPRtt

Yeah, installing the runtime and setting up trusted locations and all of that can be daunting for computer users who aren't Access people. I had to deal with that myself back in the day. I used to use an installer package called InstallShield, but I don't know if they still work with Access or not. I think someone told me they don't.

And Thomas Gonder I checked out your video briefly - thanks for the shout-out! LOL.

Good point Richard, and I'm not sure how a package would install the Access Runtime. I would be surprised if Microsoft let a package do that. I was starting with the (bad) assumption that Access (Office) would be already installed on the user's computer.

I'm glad your videos are there for me to reference. Saved me hours of adding content. I do it quite a bit in the videos I make on the ADS.

QQ