General design question - DOTNET

See if you can dump the data you will need (which should not be everything)
to a more friendly database for .NET code. The other option is see if there
is a third party driver/provider for the legacy database.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

*************************************************
| Think outside the box!
|
*************************************************
"eric" <eselk@surfbest.net> wrote in message
news:30074330-8e95-491f-b7a5-641c53f20404@26g2000hsk.googlegroups.com...
>I have a legacy ISAM database on a customers server that I want to
> access from an ASP .NET powered web-site on a different server. The
> only communication method between the 2 must be tcp/ip, and the server
> where the database is located can only make outgoing connections
> (cannot accept connections). The database has no fancy access methods
> such as SQL, ODBC, OLEDB, or anything other than a native API which
> only includes basic functions for opening/closing a table, and reading/
> updating records, nothing like sorting, adding indexes or tables,
> etc... the database has about 20 tables, including a lot of data that
> is similar to what you would find in programs like Outlook (PIM). I
> can't change the database format/engine, and I don't want to
> synchronize it to some other database format just to make data access
> easier.
>
> What options do I have, within these restrictions, to make this data
> available to my ASP .NET code. Ideally whatever I come up with would
> make working with this database as much like working with a SQL or
> Access database as possible... this way examples that I find for
> working with a SQL server, would also mostly apply to working with my
> database.
>
> I guess one route would be to create an ODBC driver for this database,
> but that is no easy task. I do realize that what I want to do is
> probably impossible, since I'm trying to take a database that supports
> virtually nothing, and expect to be able to work with the data in the
> same way as a database with full SQL support (for example).
>
> Even if I could change the database format, something like SQL or
> Access isn't going to help with the other *major* requirement -- the
> customer's server cannot accept any incomming connections. SQL
> Server, at least every example I've seen, needs to be able to accept
> incomming connections. I could build some kind of proxy for it, but
> then that probably wouldn't work well with ASP .NET, since ASP .NET
> doesn't want to communicate via my proxy.
>
> I'm hoping I'm missing something... since I do see that ASP .NET has
> things like the "ObjectDataSet", which provides the ability to get
> data from an object (which in theory could get data from anywhere).
> Also, data can come from a "Web Service". However, it still seems
> like a ton of extra work to create that extra layer, not just as easy
> as using the data browser (in VWD) and dropping a table on your page
> and being able to work with the fields, etc... Or writing a SQL query
> to do what you need, instead of adding a new method to your object/
> service everytime you want to add a page with a new query/function.
> Plus, I'd like to find something to make the tcp/ip part easier,
> between my web server and the customers server, but nothing I find is
> geared towards the database server making outgoing connections (which
> makes since, unless your customers are small businesses that are not
> capable of configuring a router to do port forwarding, and if they
> have to call a computer guy to setup my software, they aren't going to
> buy it).

On Jun 3, 8:59 pm, "Cowboy \(Gregory A. Beamer\)"
<NoSpamMgbwo...@comcast.netNoSpamM> wrote:
> See if you can dump the data you will need (which should not be everything)
> to a more friendly database for .NET code.

Wish I could, but as stated in my original post, not an option.
Although of course "not an option" could always become an option, but
I really hate to think of the amount of work required to change
database engines... since you can't see my code/design, just trust me,
this would be a huge project, pretty much a complete rewrite and
retest of the entire application.

> The other option is see if there is a third party driver/provider for the legacy database.

Seeing as how I wrote the database engine myself -- nope, no 3rd party
support for it. Although, if there was a 3rd party driver (maybe I'll
write one), what would it be that would make it work with ASP .NET
code like SQL or Access?

I'm guessing my requirements are just too much for anything other than
writing all of my own code the hard way... which I'm not 100% against,
but I also don't want to waste my time if there is an easier (and
equally robust) method.