Access 2003 in Office 2010

[valeryk2000]

Our company (~1600 users) has many Access 2003 (mdb) files, that contain plenty of VBA and ADO via SQL Server. Currently they work OK in Office 2007. But the company is moving to Office 2010. Has anybody experience with mdbs in Office 2010 environment? Any problems?
Thanks

 

[GinaWhipp]

Provided they all perform with no issues in 2007 it should be the same in 2010. However, when they get ready to move to 2013 there are apt to be some issues so I would advise to start taking the time to bring these databases up to date.

 

[CJ_London]

I agree with Gina, whilst using 2007/2010, convert .mdb's to .accdb (front ends and backends when relevant). It doesn't take long and is a simple option on the File>Options menu. Not tried it but would anticipate front ends using .mdb backends will need to be relinked.

 

[Minty]

I wouldn't use the inbuilt converter for this, it seems to mess up certain things that work fine if you do a new import. Open a new blank 2010 database and import everything into it from the current 2003 version.
This will give you a accdb that you can proof test for any issues.

 

[Simon_MT]

There is a preference for DAO or ADO - which I don't really mind.

Forms tight on screen boundaries might blow-out a little.

When importing to 2007/2010 make sure in all the all tables, the Property Subdatasheet Name value is set to None rather than Auto.

Personally, there are familiarity issues, Ribbons, no Dropdown Menus and finding things when developing is challenging.

Native image (jpg, png) formats are supported at long last.

Access 2007 well worth it, 2010 was a halfway house to 2013 and both this version and 2016 not much changed except the Web Application aspect of Access. As Sharepoint does not support VBA it is a bit inutile.

Simon

 

[gemma-the-husky]

fwiw, I issue mdb's / mde's that I develop in A2003, and have not had an issue with any access version.


Personally, I never liked A2007, but A2010 and A2013 are pleasant enough. eg - In A2003 I now miss the search bar in the A2003 database window

 

[The_Doc_Man]

The only issue to watch out for is that when upgrading, I think starting in Ac2007 (or maybe it was Ac2010) you have an option for 32-bit or 64-bit versions of Office. If you go all the way to Ac2013, not only do you have the option... but the default of that option changes to 64-bit if you don't specify and aren't careful on the installation.

Just be warned that the 32-bit and 64-bit versions ain't the same! Due to differences in the associated .DLL files, you will run into address-pointer issues for all object and ByRef formal arguments. Also, some of the external libraries you might use will need their declaration statements updated. If you stay with the 32-bit option, no such problem.

I'll tell you also that at the moment I'm running a database developed in Ac2003 but now managed by Office 2013 (32-bit of course...) with no obvious problems. So while I agree that sometimes you should try to update where possible, I also know that sometimes you can't make that leap all at once.

 

[valeryk2000]

I hope they do not plan to switch from VBA to something like .NET? BTW, is there an option to use VB.NET within next generations of MS Access?

 

[The_Doc_Man]

Access VBA and VB.NET operate at two different levels. You might be able to use VB.NET functions to launch an Access database and supply some command-line options, but the two languages aren't exactly compatible. You might also be able to create a shell from Access to run some VB.NET code, but that code would not be able to directly call an Access VBA function or subroutine.

I've heard all SORTS of bizarre things that MS will do for their scripting, including that at some point they want to include a POSIX-type shell so that you can run UNIX utilities in a Windows environment. MS has tried PowerShell but that wasn't so great. They used DOS-type scripting for a while, but that was too limiting.

I think part of their problem is command-line envy vs. all the UNIX systems out there, not to mention OpenVMS and its DCL scripting that can be managed such as running a scripted function activated with a simple command-line verb.

 

[CJ_London]

I think of VBA being the language used across MS Office products and sits on top of a lot of functionality developed in C#, while VB is for developing non MS Office related applications.

 

[valeryk2000]

Thanks everybody!