This is the Back-End Updater by Pete Hibbs

I may have put this post in the wrong place for everyone to see it, You can move it if need.

The principal could be the same for the SQL Server.
Do you have the full source to Backend-Updater By Peter D. Hibbs as you could amend it

Yes I do Alix.
I had helped him with the last update on way back in 2018.

Ya I would love to make it do the same thing with SQL backend

If you've got your own dedicated SQL Server, I would normally give each customer their own database and their own SQL Server login. That keeps their data completely separate and makes backups, restores, and customer-specific troubleshooting much cleaner.

Yes, that means you could end up with hundreds of databases, but don't think of them as hundreds of separate SQL Server installations. They're all databases on the same server. For a backend update, you can run the same ALTER TABLE, CREATE TABLE, stored procedure, or other SQL script against each customer database. With administrator access, that can be automated with a script rather than manually opening every database one at a time.

That is essentially the SQL Server equivalent of what your Backend-Updater does now. Your Access front end could still check a backend version number and apply upgrade scripts when needed, or you could keep the upgrades under your control and run them centrally on the server. I would lean toward centrally managed updates if the server is yours. It avoids depending on every customer to open the front end and successfully run an update.

Pete Hibbs' Backend-Updater was a great utility. The same overall idea applies here, but instead of copying or modifying an Access file, you execute SQL Server update scripts against the appropriate customer database.

One other approach, especially if this is more of a service that you're managing and the customers don't need direct access to the table structure, is to put everyone in the same database and add a ClientID to the appropriate tables. Then you control what each customer can read or write based on that ClientID.

However, don't rely solely on an Access form filter for that. If customers connect directly to SQL Server, enforce the separation on the SQL Server side with permissions, views, stored procedures, or row-level security. Otherwise, a determined user could potentially bypass the front end and see data they shouldn't.

You could also have the Access front end communicate with an API instead of giving customers direct SQL Server table access at all. The API would handle authentication, ClientID filtering, and updates.

There are a million ways to architect it, but for a traditional Access application where each customer has their own independent data, separate databases and logins are usually the cleanest. A shared database with ClientID is more attractive when you are centrally managing a larger multi-tenant service.

Wow you the man Richard. :)
(Pete Hibbs' Backend-Updater was a great utility) Ya, I still use it in all of my Access Apps.

Yeah I need to really get my head wrapped around SQL Server and learn it inside out.
I would rather each end user have their own individual back end SQL data file.
I was just mainly concerned on how I would update hundreds of back end data files at once.
FYI.
I will be using Winhost.

I would like for each end user to have their own individual back end data file
then when they install the program on their computer I will issue them a unique login ID password so the program will connect to their individual data file.

And the end user will not have any access to the SQL server back end.

What I'm planning to do with the Access Web Publisher that I built is very similar. Each user will have their own SQL Server database and their own FTP login on my server. A lot of people don't want to go through the hassle of setting up their own web hosting, SQL Server, FTP accounts, and all that blah blah blah, so I'll handle that part for them.

Each customer gets their own database and their own database login credentials. They will have CRUD access - create, read, update, and delete - to the tables and other objects they need in their own database, but they won't be able to affect my databases or anyone else's.

This can all be automated. You set up each user with their own database, assign the appropriate login, and point their front end to that database. In your case, the customer would install your program, you issue them a unique login ID and password, and the program connects only to that customer's SQL Server database. Since they won't have direct access to SQL Server itself, you have even more control over what they can do.

The nice part is that you can still make updates to all of those separate databases with one centrally managed process. If you need to add a field, create a table, modify a query, update a stored procedure, or remove something, you run the appropriate SQL script with administrator permissions against every customer database on the server. You don't have to manually open hundreds of databases and change them one by one.

That would probably be the easier setup for you. It preserves the separate-database model you prefer, keeps each customer's data isolated, and still lets you manage schema changes centrally. You could write a small administrative updater that loops through your customer database list and runs each upgrade script, much like the role Pete Hibbs' Backend-Updater plays for Access back ends now.

I may do a lesson or two on this for my SQL Server course, because I can see it being beneficial to a lot of people. That's the route I would go, and the route I'm planning to go myself. I just have to work out the logistics.

Would Winhost be able to handle all of this?

With a dedicated SQL Server, I'm 99% sure Winhost can handle it. I'm out of town right now, but I plan on testing this more thoroughly when I get back.

A shared SQL Server plan is definitely not what I'd use for this. You need the ability to create and manage separate customer databases, logins, permissions, backups, and centrally run your update scripts. Those are the kinds of things you generally need dedicated-server-level control for.

I pay a little over $300 per month for my dedicated server, so as long as that is within your budget, you should be OK.