I'll try not to be too long-winded, but there's a fair bit to say in order to be clear about the situation. Apologies in advance.

I do Student Records for Degree Programmes in a small theological college. I cut my database teeth on dBase III and III+, and I've been using Paradox for 15 years, through various versions, now running Paradox 10. Virtually everything I have learned has been on the fly, reading manuals, etc. and at this time, I'm really the only person left here who knows anything about Paradox in particular and the innards of a database in general -- which may not be saying much, but there it is.

There are two other programme units in the school, each with their own database sytem or lack thereof -- not Paradox.

Our Development Office, which is responsible for things like donor and alumni relations has found and embraced software that serves their database needs admirably: Blackbaud's Raiser's Edge.

There is (has been for some time) a growing desire to get the school onto one database for everything, inter-related, global, etc. Because Blackbaud offers other products with names like Registrar's Office and Records, there are those within the institution, notably those in the Development Office, and some higher-ups -- none of them with much database knowledge, if any, nor much knowledge about the administrative aspects of the curriculum -- who think that it's a simple matter of switching the programme units to Blackbaud software, and all will be well. What they do not appreciate is that (unless this has changed since I last looked) the Blackbaud products are targetted at K-12 institutions, which have significantly different curricula and reporting needs to those of a graduate school. While these products are apparently quite flexible within their targetted market, the flexibility is much less functional when one tries to fit into it something it was not designed for -- are we surprised? Not me.

Part of the interest in one unified school database is just a general feeling that that would be "good"; part of it is that the Development Office wants all contact information in one place, so that they have as broad a reach as possible to everyone who has any stake in the school.

One of the issues for us is that whatever we do, it can't cost big bucks, because bucks are always in short supply. If money were no object, it would have made sense when the conversation about one global database started to just get someone to build it for us using whatever software would do all of it. We needed a cheaper solution.

So, now we're at the point where something has to be done about the two programme units whose records are in need of an upgrade, and the question is whether to go for the Blackbaud stuff, for all programme units, and "unify" the whole school database; or acknowledge that the Blackbaud stuff can't do what we need in programme, amalgamate the three programme units in one system, and just make sure that the two databases can talk to each other.

As far as I am aware, what is required is that they both be ODBC compliant, so that one can query the other, and otherwise share information. As far as I am aware, both the Blackbaud products and Paradox are ODBC compliant. So, I think this should be a workable solution, without spending any more money on software. I am currently running Paradox 10, which I believe is the latest version.

We will need someone to build this unified records system for us, because it will be more complex than my expertise is equal to and I don't have time to do my regular job AND learn another whole whack of stuff. Also, if there are other issues identified along the way that indicate the general direction is good, but we should use something other than Paradox (don't know what those might be, but...), I'm not about to get in the way of that, but certainly can't take it on. I can and will be the point person for identifying the design needs, and the in-house support for the finished system.

My bottom line is a Records system for the three programme units that serves our needs and communicates satisfactorily with the other database in the Development Office.

I told you it was going to be long

Now, my questions:

Am I correct about ODBC compliance?
Is that the answer to the communication between the two databases?
Does this work well?
Are both Paradox and Raiser's Edge ODBC compliant?

Are there other issues I'm missing?

I've posted here, because for me it's a Paradox question, but there are other elements, so if another forum would be a better place for this thread, please move it.

Thanks for your patience and any help you can offer.

I don't know Raiser's Edge, so i'll try to answer with my general knowledge of DB development and my complete knowledge of paradox.

ODBC drivers for paradox tables are contained in Paradox 10 and runtime, so that would not be the problem.

I've searched the net, and did not find any indication of the db engine that lies at the core of Raiser's Edge, so i cannot make any assumption about ODBC compliancy.

By the way, the real problem there, afaik, is NOT gaining access to Raiser's Edge tables, since that would be a breeze having discovered which db engine they use; what would be difficult is UNDERSTANDING the structure of the tables, so that a concrete use of the data can be done, and modification can be made replicating the original functioning...

And here we are at what i see as the core of the problem.

You essentially have three different roads in front of you:
a)Stick with Raiser's Edge, and try to get the software house that created it to make more modules for it incorporating the functionality of your paradox app
b)Stick to paradox, and try to connect to Raiser's Edge data to show it up and use it without disrupting it
c)Get another app dev software (or even do it with pdox, why not?) and directly accessing both pdox data and Raiser's Edge data, try to get all the functionality in one single NEW app.

All the three approaches have distinct advantages and disadvantages.

For example, a) is the simplest one, but also the costlier one, since you would hire blackbeard to modify Raiser's Edge for your needs; b) would surely be much more economical, but i think it would rapidly delve into an inferno of trial and error on your part to discover inner workings of Raiser's Edge, just to make sure that you don't disrupt it; c) would bear nicer results, since that you'll have a completely new app, but surely it would cost more if you're trying to remain with the two separate DBs, and it would run better and be much more solid if rebuilt from scratch with only one db system.

So, it shrinks down to a simple question: how much is Raiser's Edge well documented, and how much of its inner workings its creators are willing to share with you? If you're sure to have complete docs and total support (as you have when you hire somebody to work on an open source software) then go for it, but if you'll have to reverse engineer Raiser's Edge inner workings, then the only viable solutions would be:

1)Hiring Raiser's Edge creators to expand it for you
2)Hiring another firm/person to recreate from scratch a new app fitting all your needs, if you want building on the foundation of the pdox app you have.

Bye!

Thanks for your response. I appreciate the care you have taken with it, and basically it confirms and expands on what I was thinking. So now I go back to my people and we make some decisions. Thanks again.