<div>
It should convert. &nbsp;I think the only issue would be if you have user level security. &nbsp;Did you check the references to make sure they're all aligned with what you had in the mdb?
</div>


Owner

Don Gravitt

<div>
Thanks. The recordset change seems to be the biggest issue. I'm doing a search and replace now.
</div>


<div>
&lt;&lt; The recordset change seems to be the biggest issue. I'm doing a search and replace now. &gt;&gt;<br><br>&nbsp;While it is a good idea to do that, you really don't have to. &nbsp; You just need to reference DAO and make sure ADO is un-checked.<br><br>If you are using both, then you'll be better off to be explicit and use DAO.<br><br>Reason is that both DAO and ADO have a recordset object, but are not the same.&nbsp; &nbsp;When you reference just Recordset, it will stop at the first lib reference which contains that object, which may or may not be the correct one.<br><br>Jim.
</div>


<div>
When it comes to upgrading an old .mdb to a .accdb, there are several things to be aware of:<br>-If you are just simply moving everything to a .accdb, then there shouldn't be too much to do.<br>-If you are going from a 32-bit Windows machine to 64-bit Windows, the you are going to need to add "PtrSafe" to any API declarations.<br>-Make sure you have no missing references in the VBA.&nbsp; Replace old, missing references with their modern equivalent, or change the code so you don't need them.<br>-If you want to have your app work in 32-bit and 64-bit, then you are going to need conditional compilation.<br>-Old apps were prone to use a lot of components like ActiveX controls and other things that are now "defunct" and won't work. &nbsp;You'll need to remove them.<br>-If you are switching to a SQL Server backend and will be using ADO, then you'll need to specify the recordset as DAO or ADODB. &nbsp;If you're not using ADODB and don't plan to, then no need for DAO.Recordset. &nbsp;The whole issue there is that both DAO and ADODB have an object called a "Recordset", so you need to specify which one you are using if there is a chance you may use both in your app.<br>-.accdb's have the built in date picker that is available on date field bound or date formatted controls, but you can't have an input mask - that kills the date picker.
</div>


Volunteer

Jim Dettman (EE MVE)

<div>
<div class="content wysiwyg-content fr-view">
It appears that a lot of the older VBA code doesn't run under the new version. Does all this code repair have to be handled manually, or is there a conversion that can be ran on all projects so it's not such a manual process?
</div>
</div>



It appears that a lot of the older VBA code doesn't run under the new version. Does all this code repair have to be handled manually, or is there a conversion that can be ran on all projects so it's not such a manual process?

I inherited an 2003 Accesss mdb file and have tried to covert to accdb. Converting the file presents issues with the VBA code.

Microsoft Access is a rapid application development (RAD) relational database tool. Access can be used for both desktop and web-based applications, and uses VBA (Visual Basic for Applications) as its coding language.

Microsoft Access

Visual Basic for Applications (VBA) enables building user-defined functions (UDFs), automating processes and accessing Windows API and other low-level functionality through dynamic-link libraries (DLLs). VBA is closely related to Visual Basic and uses the Visual Basic Runtime Library, but it can normally only run code within a host application rather than as a standalone program. It can, however, be used to control one application from another via OLE Automation. VBA is built into most Microsoft Office applications.