Modify form in runtime. (XP Developer)

Topic

New Reply

For better or worse, I used the Package and Deployment wizard to create a packaged database. The deployed database is a front end that links to a back-end on a network. Several users ran the setup and it works ok. So far, so good. However, now I need to make a change to one query and one form in the front end. What is the best way to make modifications to a deployed “run time” front-end database? Can this be done in the .mdb that is in the “Support” folder that was created by the package wizard or do I need to package and deploy from scratch?

Thanks,

Reply | Quote

Replies

You should only have to modify the .mdb frontend (or just have them overwrite the old one with a new one you send them); you don’t have to re-install.

Reply | Quote

Mark,
Thanks for your help. So, if I am understanding you correctly, all I have to do is go into the “Support” folder on their PC and replace the “db.mdb” with “revised_db.mdb” (I keep the same db name) and when they run the application next time they should see the revised form and query? Is this the standard way to revise deployed run-time applications? If so, is there a way to make this a little more automatic? Can I build some utility into it to check for the latest version or something like that?
Thanks,

Reply | Quote

I believe that Wendell has got something along those lines.
Pat

Reply | Quote

Look at post 205668 to checkout Wendell’s web site.
Pat

Reply | Quote

>>If so, is there a way to make this a little more automatic? Can I build some utility into it to check for the latest version or something like that?<<

There are a couple of ways to handle this. I think some of the other replies pointed you to a place for writing such a utility. I generally take another approach, which works pretty well for a smaller number of users. When you start getting to 20,30, or even more users, my approach will still work, but it becomes more difficult to manage.

On my server, I have a copy of the frontend already linked to the backend (using the backend's UNC so it is not drive dependent). Again on the server, I also have a simple .bat file which copies the frontend from the server to a specific location on the user's disk. I then put a shortcut to that .bat file in each workstation's Startup folder. This way, each time a workstation is rebooted, the latest copy of the frontend is copied down (and since it is already linked, no relinking is necessary). Fortunately, Windows affords us ample opportunities to reboot!

Reply | Quote

Wendell, Mark,Pat,

Thanks for the guidance. For the moment, a batch file that automatically copies the front end to the users pc is fine. Another deployment question has come up. We have multiple users, some with windows NT some with windows xp some with Office 97 some with office xp and some without office. The “run-time” version of the db front-end has been a good solution here. However, I put the setup.exe file and all the supporting files on a network location that all have access to and tell users to navigate to that location on the network in windows explorer and run the setup.exe. Is there a good reason to make some installation CDs and pass them around instead?
Thanks again,

Reply | Quote

>>However, I put the setup.exe file and all the supporting files on a network location that all have access to and tell users to navigate to that location on the network in windows explorer and run the setup.exe. Is there a good reason to make some installation CDs and pass them around instead? <<

I don't particularly see any advantage, but I don't have enough experience to really say.

Reply | Quote

If you’re using a LAN that isn’t too slow, the network approach should work fine. Doing it over a WAN is another story. Then either an ftp download or a CD would be a better idea.

Reply | Quote

Mark’s approach of downloading the new front-end each time a workstation is rebooted works fine on small networks (up to 10 to 20 users), as he indicated. On larger networks it can get to be a pain however, especially if the LAN is only running at 10 Mbit or is wireless. The reason is that front-ends can get pretty large (we have several that are in the 10MByte range), and when you have a 100 user LAN and everyone coming into work within a short span of time, the network can get really sluggish. In addition, if you want to deploy a new version of the front-end in the middle of the day, users all have to reboot.

The utility that Pat mentioned in his post solves those issues by only downloading the front-end when the designer updates it, and not requiring a reboot. We are in the process of commercializing it, and have it deployed at large clients here (Colorado) and in the UK. If you’d like more details, check out our web site.

Reply | Quote

Hi aap2

I stumbled on this a while ago when I was trying to answer the same question, it works automatically only when you let a new one loose, this might be of interest to others if you already found your solution.

Automatically Update Access Databases, Ken Wilkinson, Access-VB-SQL Advisor, 11/2000

John

Reply | Quote

Thanks for the tip. I’ll check it out.
aap2

Reply | Quote