DB Conversion Advice
-
Our database access code is DAO which has worked admirably for many years, making full use of the MFC DAO classes (CDaoRecordset, CDaoDatabase, CDaoFieldExchange etc.) to access mdb files. Now we need a 64-bit build and support for .accdb, does anyone have any advice on the quickest and easiest way to convert all my code? (to ADO? or something else?)
If you have a proper Data Access Layer it should be as simple as replacing it.
-
Our database access code is DAO which has worked admirably for many years, making full use of the MFC DAO classes (CDaoRecordset, CDaoDatabase, CDaoFieldExchange etc.) to access mdb files. Now we need a 64-bit build and support for .accdb, does anyone have any advice on the quickest and easiest way to convert all my code? (to ADO? or something else?)
Surely you have just one class that does all your database access! If not you now know the reason why it is so important.
Never underestimate the power of human stupidity RAH
-
Surely you have just one class that does all your database access! If not you now know the reason why it is so important.
Never underestimate the power of human stupidity RAH
You guys are so funny! ;P It's as if my code wasn't more than a decade old or something, and had been updated as technology progressed... :^) I have a single DLL of database access code comprising several classes derived from CDAORecordset and a database class containing a CDaoDatabase pointer. I think most of it will translate to CDatabase and CRecordset fairly directly.
-
You guys are so funny! ;P It's as if my code wasn't more than a decade old or something, and had been updated as technology progressed... :^) I have a single DLL of database access code comprising several classes derived from CDAORecordset and a database class containing a CDaoDatabase pointer. I think most of it will translate to CDatabase and CRecordset fairly directly.
Yah sarcasm sucks sometimes but you have seen the quality of some questions... I have never heard of a tool to convert a custom DLL to a different data transport layer. It should be a trivial matter to rewrite the DLL, ours has about 6 methods for accessing the database. It does sound like you are using your DLL for a lot more than just accessing the database, traversing and manipulating datasets I suspect.
Never underestimate the power of human stupidity RAH
-
You guys are so funny! ;P It's as if my code wasn't more than a decade old or something, and had been updated as technology progressed... :^) I have a single DLL of database access code comprising several classes derived from CDAORecordset and a database class containing a CDaoDatabase pointer. I think most of it will translate to CDatabase and CRecordset fairly directly.
Ahh, I am so used to using collections I have forgotten what it is like to access the database directly. I would suggest you may want to take a look at your architecture, I presume you are using winforms and binding the datasets to the controls which is going to entail a lot of work to change.
Never underestimate the power of human stupidity RAH
-
Ahh, I am so used to using collections I have forgotten what it is like to access the database directly. I would suggest you may want to take a look at your architecture, I presume you are using winforms and binding the datasets to the controls which is going to entail a lot of work to change.
Never underestimate the power of human stupidity RAH
Mycroft, Mycroft, Mycroft.... do I have to tell you about assumptions? :-D Winforms? Binding? We don't hold with that new-fangled nonsense around these parts! C++, MFC and FORTRAN is what Real Men™ use! (Seriously though if anybody ever 'looked at our architecture' I probably wouldn't be facing this problem! Real Men™ don't have time (or budget!) to update code that works unless they are forced to)
-
Mycroft, Mycroft, Mycroft.... do I have to tell you about assumptions? :-D Winforms? Binding? We don't hold with that new-fangled nonsense around these parts! C++, MFC and FORTRAN is what Real Men™ use! (Seriously though if anybody ever 'looked at our architecture' I probably wouldn't be facing this problem! Real Men™ don't have time (or budget!) to update code that works unless they are forced to)
Kyudos wrote:
on't have time (or budget!) to update code that works
And then someone upgrades the OS, AAaaaahhhhhh. We have about 18, relatively small, Silverlight apps in production representing some decades in man hours of work. Re building them into MVC before 2020 is going to be a nightmare.
Never underestimate the power of human stupidity RAH
-
Our database access code is DAO which has worked admirably for many years, making full use of the MFC DAO classes (CDaoRecordset, CDaoDatabase, CDaoFieldExchange etc.) to access mdb files. Now we need a 64-bit build and support for .accdb, does anyone have any advice on the quickest and easiest way to convert all my code? (to ADO? or something else?)
-
Kyudos wrote:
Now we need a 64-bit build and support for .accdb
Are you aware that the Access Database Provider can't be run in a 64bit Process? Thanks go to Microsoft. (edit: see response from Jörgen)
AccessDatabaseEngine_x64.exe is available for downloading here[^]. I would think twice before installing it together with a 32-bit office installation though.
Wrong is evil and must be defeated. - Jeff Ello
-
AccessDatabaseEngine_x64.exe is available for downloading here[^]. I would think twice before installing it together with a 32-bit office installation though.
Wrong is evil and must be defeated. - Jeff Ello