Wrox Programmer Forums
BOOK: Professional Access 2013 Programming
This is the forum to discuss the Wrox book Professional Access 2013 Programming by Teresa Hennig, Ben Clothier, George Hepworth, Dagi (Doug) Yudovich; ISBN: 978-1-118-53083-2
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Professional Access 2013 Programming section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
Old October 31st, 2013, 12:15 PM
Registered User
Join Date: Oct 2013
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Red face 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.

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!
Old November 26th, 2013, 04:15 PM
Registered User
Join Date: Nov 2013
Posts: 6
Thanks: 0
Thanked 0 Times in 0 Posts

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.

Similar Threads
Thread Thread Starter Forum Replies Last Post
code for chapter 8 of the book "Professional Access 2013"? Mike31 BOOK: Professional Access 2013 Programming 1 November 26th, 2013 04:02 PM
Advise tariq BOOK: Beginning ASP.NET 4 : in C# and VB 2 June 18th, 2010 07:31 AM
Please have a look and advise on my join mat41 SQL Language 2 August 9th, 2005 06:22 PM
OO Advise and Clarification rodmcleay General .NET 1 October 14th, 2004 09:51 PM
$ command not recognised.-Can you please advise PatrickWalsh JSP Basics 14 January 17th, 2004 09:56 AM

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