Developer / Data Entry - Two Different Locations

[bugalabuga]

I am developing a database and cover the development of the tables, forms, queries, etc...someone else is responsible for the actual data entry into the forms/tables. We are in 2 different locations. I work from home in one state and the data entry side works from home in another state.

We are currently working at different times during the day, so we just upload a newly saved copy to dropbox with the date/time. We always check with each other to ensure we are working on the most recent version.

That said, I would like to get it set up where we can work at the same time and not have to worry about constantly saving a new file, downloading that file and then uploading the newly saved file.

The people we are working on this for have a server / computer we can access through LogMeIn. Their version of access is 2007. Data entry side is using 2007, as well. I am using Access 365.

Any suggestions? I have read through the "Split a database" articles and posts and have yet to find anything that clarifies to me that someone could load data while someone else developed tables/forms...at the same time.

Thanks in advance for your suggestions!

 

[bugalabuga]

Anyone? I realize this may sound amateur...but any help would be appreciated. If there is more information I can offer, please let me know.

T

 

[xenou]

Typically it is recommended to use remote desktop or a similar protocol. I'm not familiar with LogMeIn but that might do the same thing. What you don't want is data to be sent over the wire with Access, because it is a file-based DB and any errors in remote networking connections can seriously damage the database and leave it corrupt and unusable.

Other options (besides what you are doing now) are:
HiTech Coaching for Access Databases and more ...

I do see LogMeIn listed as an option there!

 

[Tesla]

There are several solutions to your question and the answer of course "depends".
Using use remote desktop (or Citrix or other products) can work very efficiently for example:
Each user logs into a different account on a server - and has a different Front End.

Server has folder for User 1 and a folder for User 2
Each folder has the exact Front End of Access. The Application launches for the remote user on the server.

The Front-End of Access is a Split Database - it uses Linked Tables to the back end data. The back end can be MS Access engine, SQL Server, Azure, or others.
Citrix is a package that has nice drag and drop management for this kind of think. It would be overkill for 2 users. But, it works really great for dozens or even hundreds of concurrent users on MS Access front-end with a SQL Server back-end. Not saying it won't work with an Access back-end, we might need to have the "resource" discussion at that point.
Two to ten users, it can work just fine.
As mentioned above, there are some useful methods to prevent network disconnects that lead to corruption.

In these environments, my suggestion is to use Excel Object Model Programming for all reports. It works very nicely. It is the reason I am over here on this forum.
If I may suggest the Access UK Programmers forum, there are around a dozen of us that do this in produciton databases. We have many post with useful tips and code.
Tips such as using the free SQL Server Native Client for ODBC that works for networked linked tables or for AZURE.

 

[bugalabuga]

Thanks for the suggestions!

It sounds like we (me and the person doing the data entry into the tables) are both working on the back end side of it, so splitting the database seems pointless at this point in the development.

Splitting a database sounds more like a step you take after you have developed all your tables and entered your data into the tables...backend side is split for several reasons (integrity of the database) and the frontend side is handed out so people can work with the tables/data already available. That is what I am gathering in layman's terms.

Thanks again for the input. If anyone knows a way to work on the backend side, simultaneously, please let me know (or point out what I am missing in the previous replies).

 

[xenou]

There's not really a difference split or unsplit. If you split a database, the Front End(s) are connected to the backend. If you have two people working in two front ends they still work simultaneously connected to the same backend. They could use one front end the same way, with two users using one front end to connect to one backend.

It's always a good idea to use a separate front end and back end. The back end holds your data tables. The front end everything else. That's because in the rare cases that something goes terribly wrong, its usually code in the front end that does it and you don't want that ruining your database with the data in it (though everything should be backed up within some regular time frame, naturally). I think in the course of 8 years working with Access I lost a DB to corruption twice, so it can happen. Sending data over the wire with remote connections is another possible, and different cause of corruption. That's why something like remote desktop is good if you do use Access - it sends keyboard strokes and mouseclicks, but the actual processing is all on the remote pc so it's really running "locally" as far as Access itself is concerned. I'm not saying you have to, but many Access developers will do it as a matter of course.

 

[Tesla]

10+ reasons to split an Access database - TechRepublic
Will give this article a 7 of 10 for reasons for a "developer" to split a database first thing. Just a suggestion.

Totally agree, its rare. But, at a recent site of 3 concurrent users on a local network, there was a DB failure every couple of weeks.
The network was way over subscribed with everyone else's use, so it is difficult to blame Access. I will agre with Xenou that total data failures are rare.