Converting desktop database to web

[gsrajan]

I am not familiar with this. I need to publish ( if this is the correct word) one of our forms in the website so that the clients can have access to that. Is it possible to convert to web? Or it is a complete different environment and everything has to be redone for the web? Thanks for your help.

 

[theDBguy]

Hi. Completely different environment. First, you'll need to use a regular DBMS as a back end and then use web technology to create your form. There is no tool for converting Access forms into web forms.

 

[gsrajan]

Can we host the back-end in SQL server? What could be the web technology? I googled, it says php or .Net. Is it correct? Thanks

 

[theDBguy]

Can we host the back-end in SQL server? What could be the web technology? I googled, it says php or .Net. Is it correct? Thanks

Hi. Yes, correct on both counts. SQL Server or MySQL or Oracle for the database and PHP or .Net or Ruby or Vue or etc. for the web page.

 

[gsrajan]

Thank you.

 

[theDBguy]

Thank you.

You're welcome. Good luck! Please let us know how it goes.

 

[Freshman]

Hi gsrajan - did you come right with your project?

 

[mistyinca1970]

Can the backend of a desktop access database be stored on a webserver?

 

[theDBguy]

Can the backend of a desktop access database be stored on a webserver?

In my humble opinion, "No." Unless, the web server can be accessed via a LAN from your Desktop.

 

[mistyinca1970]

In my humble opinion, "No." Unless, the web server can be accessed via a LAN from your Desktop.

I placed the be on our shared drive at work, and it is crazy slow. The front end resides there as well with a shortcut that users can copy onto their desktop. Any suggestions on how to make this not so slow?

 

[The_Doc_Man]

Misty, if I read that correctly, you are using the front end from the shared drive and potentially EVERYONE uses the same file. This is not the right way to do it. Everyone should make a local copy of the FE file onto their workstation The FE should link to the BE. ONLY the BE should actually be shared. When you do it this suggested way,

A) The FE and its contents, when locally presented, have no network delays. The only network operation involves touching the BE file. Should be considerably faster.
B) The local FE and it contents, though they are files that get locked when opened, have NO CONTENTION because everyone has their own PRIVATE copy of the FE file. No possibility of lock collisions. NONE.
C) It is impossible in this case to have a lock collision on a component of the FE - which I am bringing up separately from (B) because it is the issue of lock collisions in a shared FE that is the FASTEST way to invite database corruption with accompanying loss of data.

The only down side is if you develop a new FE, you need to get it to your users.

Updating the front end on local server

Hello, I always wanted to know how to update the Fe and Be using a version number. Currently I have the Be in a folder on the local server and I distribute the Fe to each employee. Is there a way when I update the FE each person using the database FE when open it runs a version check and if its...

www.access-programmers.co.uk

Tips on General DB Deployment and/or Management

I'm to the point of buttoning up my application UI framework so that I have something that can begin to be used even if it doesn't actually do a whole lot at the moment. So, I have some unanswered questions, loose threads of ideas floating around from the various articles/forum posts I've read...

www.access-programmers.co.uk

 

[mistyinca1970]

Misty, if I read that correctly, you are using the front end from the shared drive and potentially EVERYONE uses the same file. This is not the right way to do it. Everyone should make a local copy of the FE file onto their workstation The FE should link to the BE. ONLY the BE should actually be shared. When you do it this suggested way,

A) The FE and its contents, when locally presented, have no network delays. The only network operation involves touching the BE file. Should be considerably faster.
B) The local FE and it contents, though they are files that get locked when opened, have NO CONTENTION because everyone has their own PRIVATE copy of the FE file. No possibility of lock collisions. NONE.
C) It is impossible in this case to have a lock collision on a component of the FE - which I am bringing up separately from (B) because it is the issue of lock collisions in a shared FE that is the FASTEST way to invite database corruption with accompanying loss of data.

The only down side is if you develop a new FE, you need to get it to your users.

Updating the front end on local server

Hello, I always wanted to know how to update the Fe and Be using a version number. Currently I have the Be in a folder on the local server and I distribute the Fe to each employee. Is there a way when I update the FE each person using the database FE when open it runs a version check and if its...

www.access-programmers.co.uk

Tips on General DB Deployment and/or Management

I'm to the point of buttoning up my application UI framework so that I have something that can begin to be used even if it doesn't actually do a whole lot at the moment. So, I have some unanswered questions, loose threads of ideas floating around from the various articles/forum posts I've read...

www.access-programmers.co.uk

Thank you. Yes. I can see in the early days (beta testing) having many updates to the front end, which is why I wanted to do it this way. But that makes sense.

Let me ask...if there are multiple copies of the front end, then I could potentially edit some versions of it that leave out some access (such as my secret button to unhide the ribbon).

 

[Isaac]

if there are multiple copies of the front end, then I could potentially edit some versions of it that leave out some access

You should approach permissions as just another part of the FE design. Permissions are based on user, not based on which copy of the FE the user has. All users will have an identical copy of the FE.

I can see in the early days (beta testing) having many updates to the front end, which is why I wanted to do it this way

And as far as making frequent updates, that's why I always say, BEFORE you distribute a front end to multiple users, you should FIRST choose & fully develop a method for auto-updating/version control. Common subject and much info is available by searching auto FE updater on this site.

Updating the front end on local server | Access World Forums (access-programmers.co.uk)

 

[theDBguy]

I placed the be on our shared drive at work, and it is crazy slow.

Hi. Sorry for the delay. Well, if the db app is slow when placed on a local network, it won't get any better (probably worse) if you place it on a web server. Try following the other suggestions to see if you can improve its performance.

 

[The_Doc_Man]

Concur with Isaac. Identify your users, assign them roles, and then have the DB restrict them based on who they are.

You should also arrange that your users never see anything except forms (and, of course, related reports). You NEVER show anyone your tables, queries, code, macros, and actual object names. Search this forum for "Securing a database" because there must be hundreds of threads on this particular topic.

IF your office has a domain-based setup with domain logins (password or smart card, doesn't matter how) then you can use certain system calls to identify your users and if you have a list of known users, you can assign roles to each of them. Then the forms, in the "FORM_OPEN" routines, can enable and disable controls on the form. You can also do things behind the scenes to limit visibility of data.

If you have an auto-updater script, it is even possible to have your app updated with every launch. What you do is provide a script to each user that will do the copy the new file, cleanup the old version, and then launch. The auto-updater threads include some sample batch jobs to do that, and if you do it that way, your user just clicks an icon and your app launches fairly quickly. They don't see anything of interest outside of your app.

 

[mistyinca1970]

I do have an autoexec that closes everything up. The strange thing; however, was when I had a co-worker test the distribution, she showed the ribbon unhidden. I think the network requirement asking to trust the document interfered with the macros (hide toolbar, load form modal,etc).

 

[Isaac]

You're going to hear someone say this sooner or later so I might as well ... I would recommend switching from Macros to VBA code. There are a lot of reasons why, most of which become self evident once you start more heavily utilizing VBA. It's just more powerful, easier to troubleshoot, document & maintain, and the ability to control-of-flow becomes great. But anyway that's just an aside.

As far as the security prompt vs. the startup code, what I have generally seen happen is: As soon as the user Allows or Enables as necessary, your startup form will display, and its Load event code (which is where your startup routines would probably be), then runs. Someone maybe can speak more to the autoexec, I haven't used a macro in pretty much forever.

 

[mistyinca1970]

You're going to hear someone say this sooner or later so I might as well ... I would recommend switching from Macros to VBA code. There are a lot of reasons why, most of which become self evident once you start more heavily utilizing VBA. It's just more powerful, easier to troubleshoot, document & maintain, and the ability to control-of-flow becomes great. But anyway that's just an aside.

As far as the security prompt vs. the startup code, what I have generally seen happen is: As soon as the user Allows or Enables as necessary, your startup form will display, and its Load event code (which is where your startup routines would probably be), then runs. Someone maybe can speak more to the autoexec, I haven't used a macro in pretty much forever.

I realize there is a lot more that can be done with VBA. The problem is, I don't really know VBA. I just piece together a little here and a little there. I've converted many macros and sometimes they don't convert well. I'm 100% self-taught on Access. So I try to make it work the best I can with macros and some vba. (I also don't really know SQL very well.)

 

[Isaac]

I realize there is a lot more that can be done with VBA. The problem is, I don't really know VBA. I just piece together a little here and a little there. I've converted many macros and sometimes they don't convert well. I'm 100% self-taught on Access. So I try to make it work the best I can with macros and some vba. (I also don't really know SQL very well.)

Completely understand. We all operate in the same paradigm of the tools we know and have available to us, really, so I totally understand.
Little by little - it's just an encouragement to go in one particular direction rather than the other, when you can.

 

[arnelgp]

you also need to add Persistent connection to the backend.