Access as an Application

Hi There,

Looking for some advice.
I currently have a mixture of applications held together (tentatively) by integrations.

Our main Order Processing system is on a Pervasive SQL platform which mean it's impossible for me to access core elements of the data. It's sits right in the middle of all other apps and is the weakest link.

I am looking to rewrite this system in order to bring all of our systems onto the same SQL Server database platform.

The re write would be order processing and Warehouse management.
We have such unique processes here that I see it as a possible solution get around the process issues, and to offer a cost effective solution (all be it medium term)

I know the risk of Bespoke, but even an off the shelf solution would require bespoke intervention.

My question concerns the front End.
We already hae a factory / production system written in Access (SQL back end).
This works quite well.

I was planning to re write the orders and warehouse systems using Access too.

Would you recommend this.
I know there's other dev tools out there like .net and C#.

I know Access well, and know I can deliver all the requirements and more, but would just like someone's overall thoughts on sticking with Access.

Eric HarrisDeveloperAsked:
Who is Participating?
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
I was planning to re write the orders and warehouse systems using Access too.

This is a tough call as there are many factors involved, but I would lean towards using Access.

Why?  In short, flexibility and the ability to adapt quickly.  Access as a FE or for integration tasks works extremely well.  It's a great product to use as the "glue" between systems.

I have a client now where the core ERP system is Access/SQL, and all the interfaces to outside systems are written in Access as well.  Time and time again, it's proven itself.   They are able to make shifts in business processes quickly and respond to customer needs in days or weeks.

If they were on a standard package written in C#/.Net, it would have been on the order weeks, months, or possibly years to get the features they need.   They have had this setup for close to ten years and it has served them well.

It has not been without problems however.   Access has several limitations/downsides:

1. Lack of support for third party controls - this is not as much of a problem as it once was and today, you can do just about do anything (ie. bar coding, image control, grids), but you cannot use the latest and greatest things out there.  Interfaces will tend to look dull.  There's only so many elements you can use.

2. Doesn't compile into an .exe - Because of this, it's very sensitive to environment.  We've all dealt with references, strange errors when running on servers, DLL problems, etc.   So if you have a large number of users (100+), it's a pain to deal with.

3. Doesn't do n-tier designs.   If you want to have multiple interfaces (ie. desktop and web or mobile), you'll end up duplicating your logic.

4. Access by it's very nature wants to do everything for you, which is great if you can live with it.  That's what allows you to get things done quickly.  But the downside is that more control you try to exert or it, the more it fights you.  

5. Lack of control - for example, you need (for the most part) to live within the main Access window.

 So what it comes down to is:

1. Small to medium number of users (<100)
2. How fast and flexible you need to be.
3. Can you live within Access natively as it stands?

This last point is even more important now given that Microsoft seems to no longer have any interest in developing the desktop side.  If you look at the last three releases, everything has been about the web.  Nothing new has been added on the desktop side.

  A2010 is the last real desktop version.   How long can you live with that the way it is?

 I'll end with one other thought; my recommendation to this client was that they stick with Access for the "glue" to hold systems together.   But their main ERP system is shifting to a C#/.Net with SQL backend because they want/need things that Access can no longer supply.

Eric HarrisDeveloperAuthor Commented:
That's the perfect answer
Thanks you very much for your thoughts.

I have already managed to combine the native features and developed specific requirements when needed.
I agree it's great for simple integrations. Most 3rd part apps can take a csv which is fine.

Technically I think I will be OK.

I see this very much as a medium term cheap solution. (Especially as everyone already has Off ice installed so that really gets around licensing issues.)

I will use your words as an addendum to my presentation.

Thanks again.
Eric HarrisDeveloperAuthor Commented:
An unbiased and truthful assessment
Bill BachPresidentCommented:
I understand this is closed, but I have to ask -- why is PSQL a limitation of the central data set?  You should be able to access the entire core database easily enough using either the Btrieve or SQL/ODBC interfaces.
Eric HarrisDeveloperAuthor Commented:
Thanks for that.
I see your point
However, the supplier for the 3rd party app has put a lock down on it.
I'm also not happy with the DB design itself as anything you want to do on this system takes an absolute age.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.