By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,984 Members | 2,832 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,984 IT Pros & Developers. It's quick & easy.

Access backend with HTA frontend

P: 23
I'm currently in charge of around 2 dozen Access 97-based databases in a 150+ Windows XP client environment. One of the issues I have been tasked with solving is rolling out new frontends for theses databases and I'm looking to get around the issue of deploying Access frontends for future frontend updates. As it stands, I have an MDE frontend installed on local PC's with the MDB backend on a Windows 2k3 Server, access by a network drive mapped at login.

Although it's not stricly an Access based question, I'm hoping someone can point me in the right direction of what I've seen before, which is some kind of internet-style interface, I think it might be called an HTA???

A few questions...

I'd like to know, first, is it an HTA?

Can they be linked to the current MDB files that contain all my data?

I use Access 97 SR-2 with VBA to create my frontends, what environment and code would I use to to create these new frontends? Possibly Visual Studio with VB? Or would it have to be FrontPage with HTML?

I don't want to bother any Access experts for an in-depth answer, just a pointer in the right direction for creating dynamic frontends with as little fuss as possible in converting, and then I'll start posting on the appropriate forum.

Thanks in advance, and any help is much appreciated.
Mar 17 '10 #1
Share this Question
Share on Google+
5 Replies


TheSmileyCoder
Expert Mod 100+
P: 2,321
I dont even know what a HTA is :)

But if you want an easier way to rollout frontends, you can check the post I just made in another topic:
http://bytes.com/topic/access/answer...scription-text
Mar 17 '10 #2

P: 23
Thanks Smiley, I'm not even sure if it was an HTA, it's just something that rings a bell with what I seen. I'll try looking into what it is a bit more.

I have an opportunity to influence the way future updates are handled, so thought I would look into alternative frontends instead of locally installed MDE's and thought an interface that can be updated in a similar manner to a web page would be great.

thanks...
Mar 17 '10 #3

100+
P: 157
We use this type.

We have an public area on our network called P:
On P:\ we have a shortcut which opens a .bat file.
.bat file:
Expand|Select|Wrap|Line Numbers
  1. ECHO OFF
  2. md c:\data
  3. cls
  4. ECHO Oppdaterer LogiDose, vennligst vent...
  5.  
  6. copy M:\Logistikk\LogiDose\logidose.accde C:\data /v /Y
  7.  
  8. start /MAX "C:\program files\microsoft office\office12\msaccess.exe /runtime" "C:\data\logidose.accde"
  9.  

in folder M:\Logistikk\Logidose\Hoveddose\ we have all the .accdb files which are under development or finished developed. When finished we overwrite the .accde at M:\Logistikk\Logidose\ so that the next time the user logs on he gets the new version. We also use SQL-server as back-end.

This way we can make implementation of changes to the front-end instantly. And since we can test the changes on just some users without affecting all users we have a very rapid change-development paste. Since 2009 we have made 297 new versions of the front-end of our system :=)
Mar 18 '10 #4

P: 23
Thanks, Mr Deej.

That's certainly an improvement over what we currently have, and it's certainly something to consider.

Although I've been told the central IT guys are wanting to phase out access-based databases and go with SQL/Oracle backends, so I'm wanting to get myself trained up on alternative frontends, and this HTA idea seemed to hit the spot. I can learn how to create these frontends, but (hopefully) still link them to my existing access backends before they're eventually ported to SQL/Oracle.
Mar 18 '10 #5

100+
P: 157
Yeah. All IT guys who have experienced access recommend building something in Java or another system.

We use Access only for the benefits of easy reporting and querys. All forms and functions use VBA to handle data, so that we do not have any forms which are bound to the tables.

This makes our .accdb/.accde file only uses access on the things access is good on, and the rest we use normal Visual Basic coding. You can say it is a hybrid between access and a standalone program with all the good benefits of them both.

As a middlepath you can upgrade your Acess back-end to SQL back-end. Then you will notice a significant performance upgrade on your exisisting access project.
Mar 18 '10 #6

Post your reply

Sign in to post your reply or Sign up for a free account.