May 12, 2005 at 10:44 am
I have a client who has to upsize a fairly complex multi-user financial application so that they can implement Sarbanes-Oxley audit/secruity requirements. The internal deadline is the end of this month. A previous developer estimated that he was 80% complete with the upsizing and the conversion of the Access 97 application (now in production) to Access 2003 (.adp). In addition, they've just put a RFP on the street for an COTS package to replace this. Thus my predicament.
What I've found is that the .adp file has mix of ADO and DAO including many transactions still using the DAO workspaces object. My initial look at the system reveal a lot of errors and it looks like the 80/20 rule is in full effect. There are funky errors that are hard to track down, and I fear that we're not going to get there from here.
I wanted some input about what I wanted to recommend to the client.
I'm familiar with the upsizing wizzard and SSW Upsizing Pro. Given that they're hoping to find an acceptable COTS package, I believe it would more efficient if I upsized the production Access 97 data and keep the front-end in Access 97. The project file would still be there if they can't find the COTS pkg. Meanwhile, This seems like the only way to get this done by May 31.
Summary Questions:
1. Do you agree that upsizing the data using SSW and microsoft tools and keeping the 97 front-end is the best hope of meeting the deadline?
2. Is it acceptable for an .adp file to contain references to DAO as well as ADO to have acceptable quality as a front-end to SQL Server.
Hope this makes sense, but I would value your opinons.
May 13, 2005 at 8:10 am
Well, that is a tough timeline.
The good news about upsizing with a tool on the data side is that you can have something up and testable very quickly.
I'd think that time has already run out. If the upsizing work were completed today, the organization would now have about two weeks of testing and verification to ensure that the deadline was met.
I certainly believe that when someone tells me they are 80% complete, they have no idea how much more work needs to be done.
May 13, 2005 at 10:56 am
Unless there's some extenuating reason for moving to an ADP from an MDB, I wouldn't do that in this tight timeframe. There are some real differences between the two that can easily complicate the process (as you've seen with the previous developer's efforts). The real difference isn't in whether you move to Access 2003 or stay in Access 97, but whether you change from an MDB to an ADP.
I would definitely just use the Upsizing Wizard (or SSW) to move the files to SQL, and then link them to the existing Access 97 MDB. There will be enough issues to overome in the next two weeks just doing this, but they are probably simpler issues than if you were to pursue some other approach (MDB to ADP, moving Access versions, etc.). Of course the previous responder is correct that time has already run out. If you were to leave the application in Access 97 I would assume that no changes would be necessary to the front end. There's no need in my opinion, at this late point in time, to move from DAO to ADO. I would just cut my losses and concentrate on getting the application up and running so that you can begin testing.
In direct answer to your two questions:
1. Yes, I would think that is your best bet at this late point in time.
2. I have mixed ADO and DAO in the same application, and, other than bloating the MDB a bit and having to support two types of programming techniques, I can tell you that it works.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply