Access vs Comercially available databases

Alocin

New member
Local time
Today, 17:22
Joined
Oct 18, 2022
Messages
7
Hi everyone,
Please share your thoughts if you have any suggestions.

I have been an Access database user and developer for over three decades. Now, I am wondering if anyone in this forum has heard of Automated Laboratory Information System (ALIS). I am being asked to possibly switch from my current Access database in which I have a great workflow and etc. to this commercially available Automated Laboratory Information System (ALIS).

Again after many years of access development being asked to switch over this new ALIS is a bit concerning. I do not know much about this ALIS other than what I can find on the net and YouTube. I am concerned of losing functionality for example ALIS might import the raw data but not the logic behind it, like form behaviors, event handling, filtering, or calculations and etc. Then if I cannot tweak this app for customizations, we could be looking at time and cost of migrating everything correctly, even if data import is possible, re-building what we already have in Access could be expensive and disruptive.
Again anyone heard of this ALIS if you can help justify or suggest why switch or why not switch would be amazing.

Please let me know if you have ways to perhaps distinguish concerns in performing the switch.
Thank you so much for any input.
 
When someone asked you to look into switching over to this other system, did they actually have a good reason for switching over? I don't see what the advantage is, only you can determine that. If what you have is working well, then there had better be a good reason to switch over. These commercial type systems typically have much less control over what you can customize compared to Access. That's the beauty of Access.

Just looked at the list of features they have, the one that looked interesting was this one, but it looks like it requires special equipment.

  1. Instrument Integration: When you run tests in the lab, the users should be able to follow a manual process of typing in results by hand, leading to wasted time and potential errors. Instead, data should flow automatically from the instruments to the LIMS system. This can occur via several methods:
    a. Support for “Smart” equipment, where an API connection is used to send data directly to the LIMS
    b. Support for an agent-based workflow, where an agent runs on your machines that connect directly to the equipment. This agent then integrates with the LIMS API directly
    c. Support for file-based workflows, where the instruments and LIMS have access to a shared directory, and files are ingested as they are placed by instruments.
    *For more details about the types of equipment integration possible,
    click here to access a PDF of "Uncountable's Instrument Connectivity Overview."
 
Last edited:
Interesting, I've never heard of it. At least according to my chatGPT, you lose a lot of customization abilities.

In the fight to preserve Access, remember to speak their language - i.e. speak in terms that make business users' ears perk up, such as
"I'm concerned that without customizations, we'll miss project deadlines and our reporting ability will be severely curtailed"

Don't waste too much time explaining it from a technical perspective, they may not be mature enough to want to understand/care on that level
 
We know nothing about your company (a common line of business, or a unique one?), your hierarchy (e.g. where are you placed in the org chart, and where is the asker?), your equipment (is it connected to your app), the strengths and weaknesses of your app.
So giving advice is perilous.
In your position I might advocate for a "task force" of all stake holders that is going to evaluate the pros and cons of staying with what we have, or buying into the 3rd party solution. As Isaac said very well, don't get technical; talk about the effect on the business.

On the Con side of your solution: Alocin is a single-point-of-failure. If he wins the lottery, we are screwed.
 
In my experience from the earlier part of my career, switching one experimental monitoring system to another was difficult because of having to do serious re-engineering. ALL databases based on any business have an implied data flow correlated to the physical process being monitored. If you change the base structure, you have an engineering cost OR you would have a lot of manual processing to do because the new system doesn't know how to do it. I'm not going to say its impossible but I will say I am seriously skeptical that this would be a practical idea for quick turnover to that new system. I foresee bumps in the road. Big speed bumps.
 
It's probably at a different scale to your requirement but a number of years ago I wrote a commission/bonus system for a large company in Access - it paid around 2000 sales, support and line managers and was managed by two full time support staff. New senior management were concerned about the app being supported by one person (me). So they decided to go for a commercially available package. The cost of migration was in the region of £1m and they ultimately found the system was more expensive to run as they had multiple strategic payment calculations, some just running for a couple of months, some to do with new product launches etc which required modelling - it was a very dynamic environment - plus licencing costs of course. A year after the implementation, queries from staff on incorrect/missing payments rose from less than 100/year on the access system to around 2000/year on the new, requiring additional support staff (a total of 5). A year after that, the app company was taken over by a competitor - and two years after that, they went bust - and I'm still here :)

The only thing the new system did which access couldn't was allow employees to log in and check their commissions/bonuses whereas the access system needed to send out emails with pdf's (they were grouped by manager for the manager to review and distribute on)

The point is a commercial system will typically only cover perhaps 80% of your requirements. The other 20% will have a cost in bespoking or you will need to drop from your requirements. So make sure you create a document that compares the two systems in minute detail - not just the data, but the processing time, user/group rights, the types of reports, etc
 
Thank you so much everyone.
Just to share my type of work and place. I work for a federal government laboratory in which we process forensic evidence and I maintain this evidence database. However, as with many jobs this is not my job description as it is an added take on duty. Folks before me developed this Access database in the early 90s. I took over maintaining this database in 2010.

Just so no one gets upset in this forum as I have gotten a polite reminder by someone in AccessForums.net to let folks know when the same question is posted on a different forum. I apologize to anyone if "cross posting" is upsetting to you. I was not aware of such professionalism. I am simply trying to seek knowledgeable help to write my justification why the current database is working and is not needing to be changed.

Thank you all for your replies. Very helpful!
Alocin
 
Thank you so much gentlemen. Thank you Krailo, Isaac, Tvanstiphout, The_Doc_Man, and just now CJ_London.
 
commercially available Automated Laboratory Information System (ALIS).
Re;- commercially available Automated Laboratory Information System (ALIS).

be careful some of these companies especially ones that have been taken over recently, they have a good reputation and then they get taken over by a shark ... you can become trapped by their proprietary system and they start upping the prices !!!! that's the other aspect you should explore
 
One more, perhaps relevant, story along the same lines as the others. More than 30 years ago I created my first Access database. It was minimally functional but it did demonstrate the power of automating a process. After a year or two, we decided to seek assistance from IT to correct some mistakes. That lead to a series of discussions in which the company decided to search for a commercial application. And that eventually led to lunch between a department manager and a very good salesman. And that lead to what was then a roughly half million dollar solution that took a year and another large amount to customize for our company. And a couple of years later, after I'd left, I learned they had abandoned that software.

As others have pointed out, it's really important that everyone know what problem they are trying to solve. And not be star-struck by the bells and whistles not relevant to that problem.
 
Thank you, George and Uncle Gizmo!
With all the input from this awesome group I think I have put together a decent justification. I will let share with you all if they push to replace what we have here and what problem(s) they believe will be resolved.
 
I apologize to anyone if "cross posting" is upsetting to you.

None of us gets paid to help you. The objection to cross-posting has to do with you wasting out time to work on solving your problem when you may already have a solution. Cross posters use a shot-gun approach and think they if they can get multiple people working for free on their problem, they get better/faster solutions. They don't. When you inform us that you cross-posted, we can view the other forum and see if we even need to bother with offering a solution or if you already have one.
 
Two comments:

First, @Alocin, regarding cross-posting: It is actually permissible in certain cases. For instance, you weren't looking for a solution, you were looking for ideas and justifications. You were seeking a broader set of responses. You can address future cross-posting by pointing out that you WERE cross posting (and provide a link to the opening thread), then briefly explain that you were (in this case) throwing out a wider net. Although if you were getting no answers or inadequate answers from the other post after a couple days or weeks, that is also a valid reason to cross-post.

Second, if you are looking for anecdotes on changing to newer systems: I was present at several marketing presentations when the U.S. Navy attempted to find alternative solutions for personnel management packages that could conform to military standards in an attempt to do some nice things for military personnel management. The two final bidders were PeopleSoft (which, much later, was bought out by ORACLE) and an ORACLE Forms developer team.

The committee deliberated for quite a while and went with PeopleSoft - because while ORACLE Forms had better flexibility long-term, PeopleSoft offered some interesting performance and cost-savings claims such that the difference between the two bids was about 1% of the total cost in their favor. Didn't work out, though. It was a multi-Billion dollar boondoggle that eventually got cancelled. I was in some of the presentation meetings offered to the Navy and tried to warn the Navy project manager that the cost estimate was based on a false premise and a misunderstanding of interpretive code, which is what PeopleSoft used. The project was called DIMHRS ("die-mers"). Requiescat in pace, DIMHRS.


The moral of the story is that sometimes change, even seeking improvement, isn't always a good idea if you don't have a good plan AND a good understanding of the depth of the problem before you start. If you don't understand the problem at its deeper levels, your costs are going to spiral out of control - and it could become a death spiral.

EDITED BY THE_DOC_MAN: Got the DIMHRS price tag wrong.
 
Last edited:
Two comments:

First, @Alocin, regarding cross-posting: It is actually permissible in certain cases. For instance, you weren't looking for a solution, you were looking for ideas and justifications. You were seeking a broader set of responses. You can address future cross-posting by pointing out that you WERE cross posting (and provide a link to the opening thread), then briefly explain that you were (in this case) throwing out a wider net. Although if you were getting no answers or inadequate answers from the other post after a couple days or weeks, that is also a valid reason to cross-post.

Second, if you are looking for anecdotes on changing to newer systems: I was present at several marketing presentations when the U.S. Navy attempted to find alternative solutions for personnel management packages that could conform to military standards in an attempt to do some nice things for military personnel management. The two final bidders were PeopleSoft (which, much later, was bought out by ORACLE) and an ORACLE Forms developer team.

The committee deliberated for quite a while and went with PeopleSoft - because while ORACLE Forms had better flexibility long-term, PeopleSoft offered some interesting performance and cost-savings claims such that the difference between the two bids was about 1% of the total cost in their favor. Didn't work out, though. It was a multi-million dollar boondoggle that eventually got cancelled. I was in some of the presentation meetings offered to the Navy and tried to warn the Navy project manager that the cost estimate was based on a false premise and a misunderstanding of interpretive code, which is what PeopleSoft used. The project was called DIMHRS ("die-mers"). Requiescat in pace, DIMHRS.


The moral of the story is that sometimes change, even seeking improvement, isn't always a good idea if you don't have a good plan AND a good understanding of the depth of the problem before you start. If you don't understand the problem at its deeper levels, your costs are going to spiral out of control - and it could become a death spiral.
"PeopleSoft". Hmm. Why does that sound SO familiar? ;)
 
First, @Alocin, regarding cross-posting: It is actually permissible in certain cases

My understanding is it's permissible in all cases as long as you give the disclaimer, something like "this is cross posted at " That gives people the full warnin...on the other URL activity or based on nothing
 
My understanding is it's permissible in all cases as long as you give the disclaimer, something like "this is cross posted at " That gives people the full warning, they can choose to take it on or not based on the other URL activity or based on nothing
That would be my view as well, despite me posting many cross posting notifications in multiple forums. :)
 
Think of it as full disclosure, transparency, etc. All those things we want other entities to espouse.
 
Just to share my type of work and place. I work for a federal government laboratory in which we process forensic evidence and I maintain this evidence database. However, as with many jobs this is not my job description as it is an added take on duty. Folks before me developed this Access database in the early 90s. I took over maintaining this database in 2010.
All of these companies have a Business development rep, customer care rep, Product support rep, or whatever they call it.. You contact them for a meeting and full demo and Q&A on capabilities, you will likely get more than you could possibly want and either alleviate your concerns or confirm them. No one really buys software applications anymore. Everything is subscription based. Pay by user, revenue pushed through, licenses etc.
Now the only problem is once you do this you will not be able to shake them. You will get the news letter, the follow up emails, ....
 

Users who are viewing this thread

Back
Top Bottom