Solved Transforming database from 2010 model or higher to 2003. (1 Viewer)

[isladogs]

Don’t think the OP has said what the newer version is - if 64bit, it may not convert to 32bit mdb.

Yes it will as long as its an ACCDB and any APIs are suitably converted

@GPGeorge
You're right. My earlier comment about importing into MDB files was too broad.
However, there are definite limitations.
For example, although you can import tables from an ACCDB, you cannot link to them!
I'm also fairly sure that you cannot have an ACCDB as a reference library in an MDB file or linked to tables in an ACCDB

I've just edited post #17 and will also update my article later with those corrections.

 

[GPGeorge]

Yes it will as long as its an ACCDB and any APIs are suitably converted

@GPGeorge
You're right. My earlier comment about importing into MDB files was too broad.
However, there are definite limitations.
For example, although you can import tables from an ACCDB, you cannot link to them!
I'm also fairly sure that you cannot have an ACCDB as a reference library in an MDB file or linked to tables in an ACCDB

I'll update my article later with that correction.

Good points. I stopped with just creating tables that could be imported/exported.

In any event, without knowing why the OP needs to do this, it's hard to offer very specific suggestions anyway.

 

[CJ_London]

Yes it will as long as its an ACCDB and any APIs are suitably converted

Providing the OP doesn’t then try to open the file. If they do, I doubt their client can. OP would need to provide a new virgin copy

 

[The_Doc_Man]

When you change an mdb to an accdb you get warnings, so I guess it's not trivial to reverse the process even if you don't use advanced constructs.

The basic issue - narrowly considered for the quoted statement - is that Access automatically "upgrades" to newer versions pretty well, but NEVER automatically "downgrades" to older versions. Any downgrading WILL be manually done or not done at all.

@FeelCore - my thought here is that I hope you have a time-and-materials type of contract because it is going to get tedious. (Note that I did NOT say "impossible.") A problem you might face is that to do this right, you would need copies of all of the reference libraries found in the VBA Page >> Tools >> References because a modern installation will not have those file versions and there is no guarantee that a modern version of, say, the DAO library will even TALK to that version of Access.

If you DON'T have a time-and-materials contract, the unknowns in the implied engineering to get this done will greatly imperil any chance you have to make a profit on this contract. AND if you DO have a T&M contract, you might be able to use it as leverage to move the client off of Ac2003. Because after that version, a LOT of things started changing with Access. That 22-year-old version is going to be a very hard target to reach because of the specific resources required.

 

[isladogs]

Providing the OP doesn’t then try to open the file. If they do, I doubt their client can. OP would need to provide a new virgin copy

I disagree. I often create MDB files from 64-bit Access 365. I then open them in A365 to check they still work correctly.
I then open them in an A2003 VM or A2000 VM with no problems whatsoever.

Perhaps I'm missing something in your comment but I don't see the problem (with my earlier caveats)

 

[gemma-the-husky]

I disagree. I often create MDB files from 64-bit Access 365. I then open them in A365 to check they still work correctly.
I then open them in an A2003 VM or A2000 VM with no problems whatsoever.

Perhaps I'm missing something in your comment but I don't see the problem (with my earlier caveats)

It's not creating a new dbs though. It's taking an accdb, and trying to revert it to a mdb. It can't be easy even if there are no advanced features. Maybe you can't even copy and paste objects from an accdb firm on to a mdb blank form. No doubt you can copy and paste code though. I'm not sure whether you could automate it.

I'm sure it's easy enough to copy modules and queries, but I wonder about forms and reports..

 

[RonPaii]

It's not creating a new dbs though. It's taking an accdb, and trying to revert it to a mdb. It can't be easy even if there are no advanced features. Maybe you can't even copy and paste objects from an accdb firm on to a mdb blank form. No doubt you can copy and paste code though. I'm not sure whether you could automate it.

I'm sure it's easy enough to copy modules and queries, but I wonder about forms and reports..

You can write the code to export all objects to text.

Make table with a list of all objects in the current Access.
Loop over a record set exporting the objects.
Copy the table to the new MDB in Access 2003
Loop over a record set importing the objects.

You could possibly use a version control system like joyfullservice, but I don't know if the add-on works with A2003

 

[CJ_London]

My experience is with northwind - if I download and open with 32bit access, all well and good. If I then try to I open the same file (having previously opened with 32bit) with 64 bit I get errors. Same if I open the other way round

 

[isladogs]

It's not creating a new dbs though. It's taking an accdb, and trying to revert it to a mdb. It can't be easy even if there are no advanced features. Maybe you can't even copy and paste objects from an accdb firm on to a mdb blank form. No doubt you can copy and paste code though. I'm not sure whether you could automate it.

I'm sure it's easy enough to copy modules and queries, but I wonder about forms and reports..

It IS easy providing you are aware of and deal with the issues I mentioned in post #17.
I do this regularly converting utility files such as my Access Version checker add-in from A365 to A2000 / A2003 and sometimes from there back to A2007 ACCDB. It isn't something that needs or would benefit from automation. In any case, I want to check the process manually.

RonPaii:
You can write the code to export all objects to text.

Yes of course, but still with the same limitations about unsupported objects/datatypes etc
As for Adam Waller's VCS add-in, its only available as an ACCDA file. I know it works in A2010 but definitely not in A2003.

For info, I've just finished editing the video of Adam's amazing presentation to the Access Europe User Group last week and it will be available to view on YouTube tomorrow. Link to follow in the dedicated thread for that meeting

CJ_London:
My experience is with northwind - if I download and open with 32bit access, all well and good. If I then try to I open the same file (having previously opened with 32bit) with 64 bit I get errors. Same if I open the other way round

Northwind can be idiosyncratic but I have successfully converted various versions of it from 64-bit Access to MDB files including for an Access DevCon presentation in 2023. I don't recall any significant issues but it was a couple of years ago

 

[GPGeorge]

It's not creating a new dbs though. It's taking an accdb, and trying to revert it to a mdb. It can't be easy even if there are no advanced features. Maybe you can't even copy and paste objects from an accdb firm on to a mdb blank form. No doubt you can copy and paste code though. I'm not sure whether you could automate it.

I'm sure it's easy enough to copy modules and queries, but I wonder about forms and reports..

As a test, I imported every object from an accdb into an mdb, except for tables that did not qualify due to fields with Extended Date Time datatype. Several plain vanilla tables did import. As Colin says, as long as you are aware of and deal with pertinent issues such as modifying datatypes, it can be done.

I don't know about copying controls from a form in an acdb to a form in an mdb, but that's not really within the scope of the current project anyway.

 

[GPGeorge]

As a test, I imported every object from an accdb into an mdb, except for tables that did not qualify due to fields with Extended Date Time datatype. Several plain vanilla tables did import. As Colin says, as long as you are aware of and deal with pertinent issues such as modifying datatypes, it can be done.

I don't know about copying controls from a form in an acdb to a form in an mdb, but that's not really within the scope of the current project anyway.

I converted the Extended Date Time fields in one test table to Date/Time. That table imported.
Not something I'd do on a regular basis, but as a one time project, it's doable.

 

[isladogs]

Maybe you can't even copy and paste objects from an accdb form on to a mdb blank form.

Not that its relevant to the OP of this thread but I just tested this. You can do that as well

 

[Gasman]

I seemed to import forms, queries etc without any issues?

 

[Pat Hartman]

(dont ask why)

But it is a valid question. There is no need for the client to use an old version of Access unless perhaps he is running a computer so old that it doesn't even support 2003.

If the client doesn't want to purchase a new version of Office, then he can download and use the latest FREE Access runtime version