In too deep

  • Thread starter Thread starter CJ Taylor
  • Start date Start date
C

CJ Taylor

Recently, I was charged with developing an ODBC driver for a proprietary
database.

I have no experience in developing ODBC drivers. Looking to see if there
are any resources for this other than th 3,000 - 25,000 dollar SDK's.

-CJ
 
hum, why a proprietary database
a sql server costs peanuts...
there must be a damn good reason :-)
 
The system is a legacy system written back in the 80's in thie f#$@ed up
language called Guru. It's a DBMS, expert system, and development
environement all in one. They developed an ODBC driver but it doesn't work
(well sorta, if you don't ever want to extract anything above 255
characters).

The goal of what I'm developing is to create a "Gateway" between this stupid
system and SQL Server, so I can do real reporting and data manipulation.
The system was never intended to go above 10 users (we are sitting well
above 200) but no one has been able to replace it because of current
infrastructure.

Soooooo...

We are devising a solution to do a slow transition to a new MRP by creating
gateways to duplicate data between different DBMS's. We would use the ODBC
one that came with it, but the leakiness causes machines to crash constantly
and even if you do send the username and password via connection string, its
still opens up a modal window asking for username and password.

Now, my solution (as delightfully ghetto as it may sound) was to use spy++
to get a fix on the window when it opens up, then install a message filter
in a windows service to monitor for this (I don't think VB.NET can do this
for me, so I have to write the Filter in VB6 to do a global hook, maybe I'm
wrong) and then, tell the mouse to go to a relative position and click the
OK button when it pops up.

Problem sitll exists that the ODBC driver leaks and no garbage collection to
clean it up (I'm so spoiled from .NET). So its kinda like 6 in one half a
dozen in the other. Not a solution.

So there we are. =) That a good enough reason? =)

-CJ
 
<soapbox>
FWIW, most of the information is in the MSDN library. (that's probably the
SDK you speak of) IMHO any company that is willing spend the money on
someone developing a proprietary DB and ODBC drivers, should be willing to
fork over the cash for the MSDN library.
</soapbox>

That being said, have you had a look at this? (watch for wrapping)
http://msdn.microsoft.com/library/en-us/odbc/htm/odbc_drivers_overview.asp?frame=true

You can download the source for the ODBC drivers for MySQL
(http://www.mysql.org). That my give you another place to learn from.

Writing an ODBC driver is not going to be an easy task and not for the faint
of heart, so, best of luck

Regards
Brian W
 
Brian,

Have a MSDN Universal Subscription... so you can step off your xml compliant
soapbox. =)

I don't disagree that its a diffucult an arduous task. The biggest issue
is, we didn't define the file formats, we didn't design the database, it was
all here before any of the IT department was here (in fact, in some ways I
think it was invented before some of us were even born...)

Just wanted to clear up that we didnt' develop the DB, just making do with
what we have.

Thanks for contributing to the community,
CJ
 
Sorry to jump in on this part of the thread...

I feel you pain, brother!

Maybe a "slow transition" isn't the way to go here.

IMHO it would be more feasible to get new system up and running, i.e..
tested-debugged-tested again etc. Then do a swap over-night (or the weekend)
by exporting the data from the old DB and importing the data into the new
DB.

Just my $.02. (I know, you probably don't have any control.) :)

Regards
Brian W
 
agee
go for the heavy but short pain ;-)


Brian W said:
Sorry to jump in on this part of the thread...

I feel you pain, brother!

Maybe a "slow transition" isn't the way to go here.

IMHO it would be more feasible to get new system up and running, i.e..
tested-debugged-tested again etc. Then do a swap over-night (or the weekend)
by exporting the data from the old DB and importing the data into the new
DB.

Just my $.02. (I know, you probably don't have any control.) :)

Regards
Brian W


collection half
Click to expand...
 
Brian W said:
Sorry to jump in on this part of the thread...
Click to expand...

Not a problem at all, =)
I feel you pain, brother!

Maybe a "slow transition" isn't the way to go here.

IMHO it would be more feasible to get new system up and running, i.e..
tested-debugged-tested again etc. Then do a swap over-night (or the weekend)
by exporting the data from the old DB and importing the data into the new
DB.
Click to expand...

The issue is on the swap over is still exporting the data. Plus being in an
environment that runs 24/7 doesn't help =( *manufacturing firm*

One of our primary issues is bad programming, not necessarily on our part,
but the part of a) the people that designed the system, b) our predecessors.
The amount of business logic embedded in this thing is 15 years of work, a
lot of repeat stuff with little differences in it. (A nightmare to an OO
style programmer like myself, in fact, the whole language is procedure
oriented, events are non existant, messaging doesn't exist either, the most
functionalyt it has is that you can write external c libraries that it can
read, but thats about it.

So. we have so much embedded stuff we have to start doing it slowly to weed
it all out. Check this out, you can only have one procedure per file.
Yeah... I said it, one procedure per file. The idea of a class, WHOO! Nope.
not here. 8.3 character file limits (not real suprised with an old system
like this, I just got used to joliet conventions), and a plethera of other
hindereances that stop us from doing a "quick switch"

Now, the other issue involved is picking out a new system for us. We get a
lot of resistance because source code is desired by some. I have my
feelings on that and my defenses agasint open source models (cost, microsoft
axtapa is roughly 1.2 mil w/source) but they tend to be ignored.

So I'm workign with everything I got, and yes, I know there are many many
better ways to accomplish this, but there are all these "exceptions" to my
situation..

*sigh*

But none the less, your help / suggestions are greatly appreciated. I
wouldn't be asking if I didn't want them. I just want to get the job done
right. =)

Peace,
CJ
 
* "CJ Taylor said:
Recently, I was charged with developing an ODBC driver for a proprietary
database.
Click to expand...

Did you ask that question in the database group too
(
 
Hi CJ,

But you are lucky I did not hear that it is EBCDIC so it is probably ASCII.

:-))

No flame just fun,

Cor
 
Back
Top