p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   BOOK: Professional Access 2013 Programming (http://p2p.wrox.com/forumdisplay.php?f=747)
-   -   Advise Regarding Access 2013 Next Steps (http://p2p.wrox.com/showthread.php?t=91317)

rodgerbeard October 31st, 2013 12:15 PM

Advise Regarding Access 2013 Next Steps
I've been trying to sort two questions ever since MS Access 2013 first came out. We immediately converted our entire company of some 45 folks to Office 365 subscriptions and I hasten to add that mostly, Office 365 has worked out fine. Except for one problem. Here's the background before I ask my two questions:

We run our complex, labor intensive shop floor operations (we're a a rapidly growing technology importing distributor) with a huge custom application I've developed, starting in MS Access 2007 and then greatly expanded in 2010 and 2013. This system has well over a thousand Access tables (server based), forms, views and macros and it also integrates with SQL Server 2012 and the Sage MAS 90. SQL Server is where our product structure data resides. Sage is our back office system and my system accesses it for sales orders and inventory data. (Sage runs its own DBMS accessible via ODBC.)

I'm a career s/w development mgt. guy with the prerequisite developer skills and background but lacking specific language skills (retired off and on for ten years now since my industry moved offshore). Until "upgrading" to Access 2013 we have been just fine.

But now, we have horrific data, forms and macro corruption which seems to take a lot of my time to deal with. (I've got some interesting workarounds in place if you're interested.) The bugs in Access 2013's desktop UI interface take a lot more. The company is growing rapidly and there are many new applications features I want to introduce. For example, I have a CRM front end written and ready after I work around the latest Access bugs. (To be clear, I don't mean programming logic bugs. I mean compiler bugs acknowledged by MS TechNet.)

OK, you're probably wondering why I haven't converted to VBA long ago, right? Originally this was because we wanted to migrate to thin client (browser) and ultimately provide certain customers access to certain data. I dabbled a bit in Access 2010 and decided to wait for 2013 due to its well known issues. Access 2013 is much better for browser deployments of course. However it requires SharePoint and we are way too small to need, want or afford it. (We already have it via our 365 subscription but our staff is 2 in IT and I am the sole developer. I know from past lives that the support requirements would kill us!)

My questions:
1. Will migration to VBA solve the majority of our corruption problems and macro related issue? (I view this as a one way bridge. Once across I probably can't go back.) What I'm probing is whether we have simply outgrown MS Access, even as a SQL Server front end which was where I was trying to head.

If the answer here is "it depends" then why and what does it depend on?

2. If we just ditch MS Access altogether, what is the right language(s) (high-level preferably) and what are the logical (hopefully bite-sized) migration steps to get our mission critical system converted? One key consideration is time, both to learn and then convert. This is a one man, self taught band. [8]

If there are multiple answers and/or "it depends" here too, then please provide as much clarification as you can. BTW, we are a 100% MS shop and I have already been dappling with Virtual Studio 2012.

Thanks in advance for your advice!

DougY November 26th, 2013 04:15 PM

Hi Rodger,

It's hard to give you a definitive answer but for a desktop database, VBA will probably ease your pain, and if it won't initially, it should be easier to debug and fix.

Re moving away from Access -- if you already are dabbing in VS12, you can look into re-writing the solution in .Net It will not be as easy and as flowing as Access, but it is the next large step up. However, you should consider the cost involved in developing and maintaining .Net solutions versus Access solutions. I'd recommend trying to work on the Access platform until you have to choose a different tool.

All times are GMT -4. The time now is 02:28 PM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.