Microsoft Access Support Requirements (1 Viewer)

[LouiseC]

Hi All, a new member here!
Recently my company purchased, via a developer, an Access database application. The question I have is, what should we be asking for in terms of support?
I’m looking for is a list of support requirements that are known areas of concern for MS access applications and databases in general.

 

[The_Doc_Man]

Are you suggesting that the purchased product is some kind of "canned" Access-based application?

In essence, you need to know the same sort of things you would need to know about buying a car with a product warranty. Software can break in numerous ways. Know what is covered and what isn't. You need to determine the level of support you get from your provider.

The standard questions will be "length of software warranty" (90 days? 1 year? Renewable support contract?) and "response time to errors" and a clear definition of what constitutes product misuse or abuse to a level that would void any warranty. Specific questions would have to include "support rights in light of published Microsoft patches that have the result of disabling the product." (It can happen!) Determine if the product has been sold with the idea that it will be maintained by the supplier or whether you implicitly take over maintenance the moment you buy it. (i.e. implies the need to hire a support person.)

One important factor is whether you were provided with a "user's guide." Another is a "maintenance guide" - particularly if you are in the "user provides maintenance" situation. You need to carefully delineate what is YOUR responsibility vs. what is the provider's responsibility, spelled out in careful terms. This is going to sound Draconian, but if your company has the means to do this, you should investigate your state's law on mercantibility, i.e. determining whether a product is suitable to be publicly sold.

 

[Pat Hartman]

Technically, software doesn't "break". If it works, it continues to work forever. That doesn't mean that it is being delivered to you with no undiscovered bugs. Things that have "broken" my "sold to the public" software over the years are mostly related to new versions of windows and new versions of Office. When the software was sold, the users were told what version of Windows and what version of Office we would support. So far, we've gotten through four versions of Office and three of windows without me having to make any updates which doesn't mean that MS isn't going to break it tomorrow. We've had a few issues though but the biggest one was last year when they "upgraded" to a cloud server last year and didn't bother to run it by me beforehand. That was a mess but I finally convinced the IT people that they had to listen to me when I told them how the app needed to be distributed. The software hasn't been updated in 10 years. I've offered updates but the clients just like the way it works. it does what they need it to do and they are still very happy with it

Do you have the sourcecode? If you don't have the sourcecode, you won't have any way of actually fixing any errors that are not related to the "environment" and even then, you might not be able to resolve the problem.

Hopefully, you have documentation - both user and developer.

If you are reliant on the developer, you need a service level agreement which defines the response time to fix bugs and an annual contract. Bugs range from annoying to work stoppage. The more important the app is to your day to day operation, the higher level of support you need.

 

[arnelgp]

Recently my company purchased, via a developer, an Access database application.

you buy also the code, so Anyone here can be of support to you and perpetually free.

 

[Galaxiom]

It is vital that the developer provides a mechanism to release the source code to their customers in the event of their own demise.