The answer is yes, but it would be very difficult and time consuming. In our opinion you would be much better off simply starting over than converting the Access 2.0 code.
The first hurdle is the MS Access security that was applied to all the database objects. See the section on this website titled QuickLaw Security to create a QLOwner user in your newer version of Access.
We used a number of 16-bit o/s calls that would need to be changed to corresponding 32-bit calls. We didn’t a whole lot of this, so it shouldn’t much of a problem. Converting these probably wouldn’t take a good programmer more than a couple of days.
We used names of objects that have since been made keywords in Access. In particular, there is a module named “Forms” which is particularly troublesome. You can’t import or open this in Access XP. The name has to be changed with a copy of Access 2.0 before you can import it.
We recommend purchasing a program called Speed Ferret (www.SpeedFerret.com) to globally change all the keywords that you find. It’s finding them that will be difficult.
QuickLaw was integrated with Microsoft Schedule+ for the calendaring. This program is no longer available. You could change this to use Outlook using the same type of calls and integration, but Outlook calls are completely different. A programmer with Outlook or Office experience could probably convert this to Outlook in about 40 hours.
We went to a great deal of trouble when we wrote QuickLaw to keep people from simply copying it to additional workstations. Back then we wanted them to purchase additional licenses. Because of this the VB code in QuickLaw has all kinds of convoluted licensing procedures and hidden forms that would make very little sense to anybody simply trying to convert the program. This would pose a pretty serious block to conversion of the program.
Converting it to use the latest versions of Word and OmniForm shouldn’t be much of a problem. It’s probably as simple as setting the objects to the latest version and you are done. Heck, it might just work fine with no changes.
Porting the data to SQL Server or the MS Data Engine would be a huge job. All of the queries would need to be converted to SQL Server dialect, a time-consuming proposition. We feel it would be easier to write a completely new program than try to use QuickLaw and update it to use Access XP and SQL Server.
If you use the newer “linked” version of QuickLaw you can easily run 15-20 users simultaneously and get reasonable speed. I wouldn’t consider SQL Server unless you run more than 20 users.
If we haven’t convinced you NOT to try this yet then don’t say we didn’t warn you. Start by creating a QLOwner account in Access and logging in. Remove all security from all objects in QLData.MDB, OLEOpen.MDB and QLOpen.MDB. The first two only contain data. The third file, QLOpen, contains all sorts of objects (forms, modules, macros, queries, etc.)
Converting the data files (QLData and OLEOpen) should be easy. If you can’t convert them just import them into new files with the same names.
Converting the program (QLOpen.MDB) will be tougher. The queries shouldn’t pose a problem but the VB code will cause all kinds of headaches. Figure at least three weeks to convert all this working full time, and it could be as much as 2-3 months.
Converting the other databases, like FileFix and QLSetup shouldn’t be too difficult. Don’t bother with these until you have successfully converted QLOpen. Converting these files would probably take another three weeks to a month.
Good luck! If
you actually do it please let us know. We would love to see it!