I have a problem need dirrection or advise.

[Jon123]

I have a access database that is not split because users work out in the field and most can not connect to the internet. So I have a database that has procedures or checklist that are created in forms. So say a procedure 1 has 5different forms and 1 table that holds the information for that checklist.
User 1 starts a procedure but does not finish it. Is it possible for him to export the forms and the table to another user and in turn the new user can input the data and continue with the procedure?

any input or ideas on doing this please advise

jon

 

[ezfriend]

You could probably have user1 export the data to a text file and user2 then can import into his database. Please note that things like primary key that get increament automatically will change, but since you only use one table, that should matter.

Just have the user export the rest of the fields to text file (excluding the ID field). The second user should be able to use the text file and load it directly to the table.

Look at the "DoCmd.TransferText acImportDelim" to help you import the text file if not using the wizard.

-EZ

 

[HiTechCoach]

jon,

Before I did anything, I would split he database. I have never found a reason not to, only many reason why it should be done.




.

 

[Jon123]

Why split it if I dont have a reason for a frontend vs backend the users dont have access to the network. This will just make it harder for updating them.

jon

 

[HiTechCoach]

Why split it if I dont have a reason for a frontend vs backend the users dont have access to the network. This will just make it harder for updating them.

jon

This will just make it harder for updating them.

Actually it is just the opposite. A split reapplication is much easier to update.

I always split database even if single user and/or all on the local machine. It is much easier to update, less corruptions, more stable, etc. ...

 

[Jon123]

Really, I did not know that. So I can split it. So is it best to keep an unsplit version that you modify and improve on and just keep splitting as you update? or does that not matter?


jon

 

[gemma-the-husky]

surely it would be easier for you field guys to enter data into excel, rather than access - then you can just import the data from excel, or from a csv

probably easier for them to use, and cheaper for you, as you dont need to give them access.

 

[HiTechCoach]

Really, I did not know that. So I can split it. So is it best to keep an unsplit version that you modify and improve on and just keep splitting as you update? or does that not matter?


jon

jon,

I find no need to ever have an unsplit version. I start every database split and keep it that way. It makes every thing easier to keep them split. For example, I can link to a back end that is test data during development.

If you deploy your database as split, then you really should develop it split or it will be very had to test as you go if you have to split constantly resplit the database to test the new changes.

Before I learned to spit all database ( that was over 15 years ago) I would develop an a "developer copy" and when tested out, I would import he object back into the "master copy". We never did development on the "master copy." When new changes were require, we made a "developer copy" of the "master copy". Otherwise there was no way to test and experiment and enter data without possible destroying the "master copy". The to deploy the change from the master, we have to import the changes into the "production database." That is a lot of work and pron to errors.


With the database split, to deploy an update, you just replace the front end. Could not be much simpler than that.