Continue developping

[hfsitumo2001]

Hello,

I keep continuing in development of my supplies database while it is going live. What is the best method to do it. I can do it in the office, but when I want to do it at home, the link path of the table after it was split, is different. What I had in mind, I export the link path at home to excel, the in the office I import it the developped ones, since it was already in the software, when I run it at home it could work.

But I am not sure if can work because the link in the office becomes the wrong path.

Anyone can help me on this.

Thanks

Frank

 

[The_Doc_Man]

The usual way to develop is a form of multi-entry bookkeeping. You make a developer's copy that you use for changes and experiments. You make a test copy to see what if you have is viable. Then you stage a production copy that is the one you actually will distribute.

The DEV copy can be anything and do anything because it never sees the light of day until you are ready for testing. It has its own back-end DB that never sees daylight either. The DEV copy of the BE could start life as a copy of the real BE file, just one that you keep private for testing and other work. If you intend to secure this DB, you don't do that on the DEV copy because only you will ever see it. You need to be able to manipulate it in ways that your end users would never be able to do. So it needs to be wide open - for you, who is its only user. IF you have not already done so, search this forum for "Securing a Database" as a topic for study.

The TEST copy has to be something you would consider allowing someone to use - if it passes your functional tests. It has its own back-end DB that doesn't see the light of day either. Could be the DEV BE file or could be a copy of it. But it still hasn't been customized or finalized and it still doesn't touch the REAL BE database.

The STAGE copy is one that has passed the tests and is worthy of exposure. You have to make a list of "final customizations" or "final adjustments" that you don't do for DEV or TEST. You test it one more time with the TEST DB, but then you change the links to the production DB AND you finish the steps for "Securing a database." At that point you have the PROD copy that you publish for your end users.

There is also a topic you can search here called "Distributing a Database" that tells you how to automate the process of updating the users' copies of the PROD database painlessly.

 

[Pat Hartman]

When you move your dev FE and BE to your home system, you simply relink the BE using the path on your home system. When you bring your copy back to the office, relink it again. When you have tested your changes and you need to deliver them to the users, you backup your dev version and then relink it to the production BE. Then you move the Dev FE to the production distribution folder on the server. Then your normal distribution should take it from there.

For my own personal sanity and to prevent accidents, I always use different names for my test and prod files. So I might use:
MyDevFE.accdb and MyDevBE.accdb and MyProdFE and MyProdBE.accdb

You can never be too careful with your dev practices. Always make sure you have a backup before you make ANY changes and then backup again after you make the changes.

I use a .bat file run by a shortcut for my users to open the app. The .bat file automatically copies a fresh copy of the FE each time it opens. Some people use a database to cause a new version to download. There are multiple solutions to the distribution problem.

 

[Eugene-LS]

Anyone can help me on this.

https://www.access-programmers.co.u...db-to-front-end-database.322695/#post-1820593

 

[Gasman]

What is your office path? Does it use UNC or Drive letter
You could just duplicate that path on your PC if drive letter?

 

[hfsitumo2001]

When you move your dev FE and BE to your home system, you simply relink the BE using the path on your home system. When you bring your copy back to the office, relink it again. When you have tested your changes and you need to deliver them to the users, you backup your dev version and then relink it to the production BE. Then you move the Dev FE to the production distribution folder on the server. Then your normal distribution should take it from there.

For my own personal sanity and to prevent accidents, I always use different names for my test and prod files. So I might use:
MyDevFE.accdb and MyDevBE.accdb and MyProdFE and MyProdBE.accdb

You can never be too careful with your dev practices. Always make sure you have a backup before you make ANY changes and then backup again after you make the changes.

I use a .bat file run by a shortcut for my users to open the app. The .bat file automatically copies a fresh copy of the FE each time it opens. Some people use a database to cause a new version to download. There are multiple solutions to the distribution problem.

Thank you Pat, that is the way I had in my mind, but when I relink it in the office to the home path, Can I open it at home?.

Thank you

Frank

 

[Pat Hartman]

If the paths are the same, Access will just open the BE. It doesn't connect until it needs to. That's why you can just replace the BE with a file of the same name and the FE doesn't blink an eye. People who download spreadsheets or text files, frequently reuse the same name for the external file so that the links don't break

 

[hfsitumo2001]

Practice your Choir by learning voice by voice. You can play it on the youtube in the big TV screen and you can see the active highlighted in the staff is the voice being played for you to follow.
Joy To The World_Alto

In the office it uses UNC, I do not think it works at home.
Frank

 

[Pat Hartman]

If you have the same path at both places, it works whether it is UNC or not. It is very unlikely you have the same path at home if you are using a UNC but you could if you had a home network.

To save yourself some trouble, copy and paste the UNC into a table in the FE. That way, when you move from home to the office and back, you can just copy the UNC and paste it to simplify the relink.