View Single Post
  #1 (permalink)  
Old October 31st, 2013, 12:15 PM
rodgerbeard rodgerbeard is offline
Registered User
Points: 5, Level: 1
Points: 5, Level: 1 Points: 5, Level: 1 Points: 5, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Oct 2013
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Red face Advise Regarding Access 2013 Next Steps

Hi,
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.

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!
Rodger
Reply With Quote