Just took the standard customer form and rearranged it and laid it out in cell phone format, and the Publisher did the rest.

Yes, this fits perfectly on my cell phone

Now you're probably wondering why certain objects don't exist on the main menu. Well, images I haven't gotten to yet, and you can hide buttons that don't do anything by using the NoWeb tag, and then they just don't get published.

And likewise, we have our own OpenForm tag to open a form, obviously.

And for now, OpenForm has one parameter, which is True. If that's the case, it opens up that form and filters it based on the primary key of the form that you're on. This way, from the customer form you can show just their orders.

Passwords are not stored in the linked tables.

One of the big problems with Access security, with linking tables to SQL Server, is that it sometimes stores the passwords with those links. I specifically did it so that it needs the password, obviously, to make the link in the first place, but then it doesn't save that in the database. You will, however, need to relink one table when the database starts back up, and I'll provide you with the code to do that or a button. Once it's linked, that's it. The password is stored in the VBA code, so as long as you compile it into an ACCDE and give that to your user, they won't get a hold of the password.

This is the Form Publisher, where most of the work gets done. Start by selecting the Access form you want to publish and give it a description, which becomes the page title on the website. Next, specify the primary key field and the primary key table. This is necessary because a form can be based on a query instead of directly on a table, so the publisher needs to know where records are actually being added, edited, or deleted.

Speaking of queries, forms based on queries are supported as long as the query exists on the SQL Server as a view. Right now you'll need to create those views yourself, but I'm thinking about adding a Query-to-View converter so the publisher can generate them automatically. As long as your calculated fields exist in the view, they'll continue to work just like they do in Access.

You can choose whether a form is read-only or editable, decide whether it should display a Home button, and specify which page serves as your application's home page, such as your Main Menu form. There are also options to allow or prevent adding and deleting records, and the publisher keeps track of when each form was last published so you know which pages need to be updated after making changes.

Finally, there are buttons that will generate the web page, upload it to your web server automatically via FTP, and open it in your browser for testing. You can also do all three steps with a single click, which is the option I usually use.

This is the Settings form, where you configure everything the publisher needs to connect to your SQL Server database and your website. Just enter your SQL Server name, database name, username, password, and then your FTP server information, including the server name, username, password, and port number.

Yes, you will need your own web hosting account with SQL Server support. But as I've mentioned in about a million videos over the years, hosting is incredibly inexpensive these days. A company like WinHost offers website hosting with SQL Server for around five bucks a month. Honestly, if you can afford my lessons, you can probably afford five dollars a month for web hosting. I don't want to hear any excuses. It's cheaper than a fast-food lunch.

You'll also specify your local Access database file. Right now the publisher assumes the database is in the same folder as the application, which is the recommended setup anyway. You can also specify your Main Menu form, which becomes the destination for the Home button on your generated website. The output and temporary folders generally don't need to be changed, so you can leave those at their default values.

You'll also enter the URL for your website. There are several support files that need to be uploaded to your web server, including JavaScript, ASP include files, and other helper routines that don't change very often. One of those files also contains your database connection string. There's a button labeled "Upload Required ASP Files" that takes care of all of that for you. Just click it during the initial setup, and it'll upload everything you need. I'll cover that in the setup instructions.

There are also a few utility buttons. You can test your FTP connection, test your SQL Server connection, and remove any saved usernames and passwords. That last one is mostly for me, so before I build the ACCDE for distribution, I can strip out all of my personal server credentials with a single click. There's also a "List TempVars" button that I originally added as a debugging tool, mostly for Adam and me while we were testing. I'll probably remove it before the final release, so you can safely ignore that one.

This is the SQL Migration form. The first thing you'll do is load the table list. The publisher scans your local Access database and populates the combo box with all of your local tables. Select the table you want to migrate, and it'll automatically fill in the SQL Server table name using the same name as your Access table. I recommend leaving it that way. You can certainly rename it if you want to, but if the table names match, your forms will continue working without any additional changes, which makes life a whole lot easier.

From there, you can create the SQL Server table with a single click. If you're making design changes and need to start over, there's also a button to drop the SQL Server table, although you'll want to be careful with that one since it permanently deletes the table and all of its data. Once the table exists, click Copy Records to migrate all of the data from Access to SQL Server. Is it the fastest migration tool in the world? No. If you've got a few hundred or even a few thousand records, it'll work just fine. If you're moving millions of records, there are better tools for the job. But for the kinds of databases most Access developers work with, it gets the job done with almost no effort. When the copy finishes, you can delete your local table, relink your Access front end to the SQL Server version, and you're off and running.

Over on the right are a few convenience buttons. There's one to reopen your original Access database before you start deleting or relinking tables, just to make sure you've got the correct database open. There's another to test your SQL Server connection, and one of my favorite features, Add Relink Module. Clicking that button automatically inserts a VBA module into your database containing all of the code needed to reconnect your linked SQL Server tables at startup. All you have to do is call the reconnect routine from your startup form or Main Menu, and you're done. I wanted to make the migration process as painless as possible. Even a caveman can do it.

Just WOW!  Although I won't even begin to pretend to know how all of this works... it certainly sounds impressive.  Great job Richard!

Wow. That looks amazing. You have certainly been busy over the weekend.

Wow, That looks awesome. As Kevin says you have been busy.

You always positive when teaching us but this page expresses a "kid in a candy store" feel. Glad you are having fun!

Great work, Richard!!!  Make sure you lock down the IP (Intelllectual Property).  This could be a game changer!  One day I'll be able to say "I knew Richard before he became a "bazzilionaire"!  LOL!!!

Sam I'll be releasing this one as an ACCDE template so people can use it, but the code under the hood is staying proprietary.

Richard, You Make me want to work for you maybe just to hang around and watch and learn from the Master! This Database is definitely a game changer for a lot of us! Looks Amazing. Can't wait for the release.

WOW!  You sure are an Over Achiever.!