1 Access Application, Multiple Developers? (1 Viewer)

Hi everyone.

My company uses Access 2013 for its product data and customer data. The amount of work and development required is growing fast, and we are considering a second Access Developer.

I am not sure whether two developers can work on the same Access 2013 application at the same time?

Any thoughts / suggestions please?

Alan

it's not easy.

you can split functionality, and develop entire forms, or "black box" routines, and then merge them together. Clearly you need a split database, an agreed set of standard functions, and a disciplined approach.

Thanks for the thought. As our second developer would be relatively inexperienced, I think that may cause more issues than solutions.

Sure they can. It's called source control (http://en.wikipedia.org/wiki/Revision_control). It can be as easy as sending an email to the other guy teling him what you are working on or there's thousand dollar software that you can use to make you be coordinated in your efforts. And that's really what its about--communication and coordination.

Instead of thinking of what you are working on as this hideously complex piece of software called a database, think of a Word Document that a team is working on.

Jim handles the Sales piece, Brad writes the technical details, Mary writes the introduction and conclusion, and when you are all done Lisa proofreads it and ties it all together.

Its really that simple--just communicate before hand and let each other know which part of the database you are working on. Nobody really needs to be in the Main copy doing their work, they can all work on their own versions and have Lisa be in charge of the Main copy.

That's what I would do in Access. Have a production copy and then when either of you are going to make changes you copy that production file, work in that copy and then move your changes back to the production copy. Maybe even have a spreadsheet where you go to mark the date and the piece you changed (or are in the process of changing) so that the other guy knows whats going on.

Communication and coordination.

As stated above, communication is paramount.

Central data, either split database or SQL Server Express.

Crucial is naming convention. You might even consider using a simple table that contains major objects names so they will be unique from database to database.

We have some objects that are universal to all our databases. we put them in template databases and use these templates to start new projects.

During development we put all modules, public variables, and functions, in a single database. All front ends have a reference set to this database.

Only compiled front ends are sent to users, we use KenHiggs version manager to accomplish this.

Everyone needs to be following the same design requirements, and regular meeting to determine conformity.

Color themes and layout should be consistent, and ALL non obvious code must be remarked.

If Access 2010 is an option then you can use Microsoft's native source control support.

Microsoft removed source control from Access 2013 - presumably in line with their positioning of Access as an power user tool rather than a developer tool.
http://technet.microsoft.com/en-us/library/cc178954.aspx