The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Moving app from BTrieve to SQL Server 2005

As stated, I've been tasked with moving a BTrieve app to SQL Server 2005(C++).  I have a pretty good idea on how I want to do it but I thought I'd get a few opinions first.

Internally the app actually uses BTRV++ (C++ wrapper for the C API).


Option 1 is reimplimenting the BTRV++ API to use SQL Server in the background simply as a means of "getting it on there" and from there slowly moving the app off of the wrapper directly onto SQL Server (whilst also making it "relational").

Pros
* Get's it on there
* Done in several stages
* Shows "progress" to management

Cons
* Overall will take longer
* Pointy haired boss may try to sell it before it's done properly
* I'm a relatively young programmer and BTrieve is new to me, I would have a lot to learn about BTrieve's behavior


Option 2 is to simply start reimplimenting the backend to use SQL Server 2005.  The software itself is *not* layered (ie, data layer, model layer, business layer, et al), however, it does appear to be layered vertically.  The front end and the back end are horribly intermeshed but the functionalities of the software appear to be pretty well independant of each other (as much as possible).  This, I believe, would make simply converting it over a tad easier then if everything were horribly convoluted (rather than somewhat convoluted... heh)

Pros
* It'll be done when it's done and not before
* Will most likely be done faster
* Less error prone for me as I'm more familiar with the tools involved


Cons
* Won't "appear" to be finished as quickly for management
* Won't be done in nice defined "stages" that management can see



Personally I'm leaning more towards Option 2.  I've been told that the "BTrieve Customers" will stay on BTRieve and we'll be looking for new customers for the SQL version.

However, this will be a first for me porting an app from one platform to another and I'd like some input.

Also, if anyone knows of the existence of any wrapper dll's for either the C BTrieve API and/or the C++ BTRV++ API do tell :)

Thanks
Ignorant
Wednesday, May 09, 2007
 
 
From the little hands-on experience I've had with the Btrieve API, I think that you'd be going down a very rough road with option 1.

Most large Btrieve systems I've seen isolate all of the Btrieve calls in a single IO module as part of abstracting the implementation details of Btrieve interoperability from the application programmers.  That's what I'd be looking for if I were facing your project.

If an abstraction layer doesn't already exist, building one is not likely to be trivial, but it's probably the right thing to do.
Robert Rossney Send private email
Wednesday, May 09, 2007
 
 
If I went with option 2 what I'd do is look at each "set of functionality", go through the objects and put a layer between the objects and the data (DAL), and so on and so forth until the data access had been pulled out of the business objects.  Then I'd go back through and do the same thing, only this time pulling the interface out :)

They have classes that interact directly with the BTRV++ library that's throwing up dialog boxes, et al, as well as their "business objects" (that isn't truly what they are) working directly with blind data buffers and the like.

They have a layer of abstraction but the problem is that it's the wrong abstraction.  Their frontend is working with a file manager, files & buffers rather than data, and they have access to all of this because their business objects inherit from a "record object" where by record they actually mean table (that threw me for a loop).

I don't fault the creators of this beast as it's an older piece of software using older technologies, but I'd personally like to layer this software.

And if anyone has an option 3 let me know :)
Ignorant
Wednesday, May 09, 2007
 
 
In the past I've come up with a base class to represent a btrieve file. I then created classes for each particular Btrieve file inheriting from the base. I've updated the application to use the classes and then migrated the classes to SQL Server.

I only added things to the base once I found them in the source. Most of the Btrieve API isn't really used that often. 

The biggest problem I had was accounting for the random btrieve file which held multiple record types. For example if a certain byte was 1 it's a PO header, if its 0 it's a detail. Thank goodness it didn't happen to often.

You will also need to come up with a way to handle transactions assuming your original app used them.
Phil C Send private email
Wednesday, May 09, 2007
 
 
Second worst thing that happened was records where someone tried to mimic a multivalued database. I.e. a "field" would have sub-fields with values seperated by a high value ASCII char like 253. This need to be broken into a master detail setup in the relational db.
Phil C Send private email
Wednesday, May 09, 2007
 
 
Since the Btrieve customers won't be upgraded, why not just start with a clean slate and build it to the best of a) current design best practices, and b) to take advantage of the technology platform (SQLServer, C#, .Net, etc.)?

In other words, why waste time trying to migrate the application, when you really only need to duplicate the functionality?

That way you can lock down the BTrieve version, move to the new version, and give the product long-term flexibility for future growth.
*myName
Monday, May 14, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz