Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
1) Enlarge your Access system to encompass all functionality. I've written deeper managed systems in Access (and some are still in use, LOL) which is fully capable of handling all the necessary tasks with appropriate scripting. But when you get larger
2) Graduate to MSSQL and scripted applications moving your data. There are many different ways to approach this, of course, as virtually every application builder, language and script type speaks SQL in some fashion. But the concept of centralized data storage with scripts reaching in to accomplish tasks and interfaces allowing you to manually modify the data is hardly new. The advantage of MSSQL of course is that many users can access the data instead of a single workstation. Even if you "share" the DB file in Access you don't have a true multi-user system until you can all access it at one time and make concurrent changes (a good trick in Access, but normal in MSSQL).
3) Super-Graduate to MySQL and port the entire operation to a free licensing envinroment (otherwise the same description as MSSQL! LOL). In addition to the free licensing, the programmers available in the Linux world are fairly plentiful and do not (as a rule) expect to get $30k for each application. Just remember: Don't send money to a company you cannot sue until after you have your product. Especially to a location where $500 is two year's Salary and the programmer would do better economically to disappear with that money than actually build the application! I like "one piece at a time" small script building solutions. It builds a relationship between developer and client while providing useful results with smaller amounts. And keeps the developer busy with lots of little clients (so no single client can "shut down" the developer
All the above are assuming that scripted systems can modify what needs to be modified when conditions change. Also all assume you have knowledge of at least one language or scripting language to make these changes. Generally this sort of thing is handled one item at a time, starting with the most "work-hours-intense" piece (to recoup those man-hours as quickly as possible). This is something most IT shops do for clients on a daily basis: Automation. The fact that you ARE an IT shop does not make you immune from the need to have automation! LOL