[My reply is below, after the question...  scan down.  VDC]

On Friday, March 8, 2013 7:33:27 AM UTC-7, Javier Guerra wrote:
>
> On Fri, Mar 8, 2013 at 4:25 AM, VernonCole <verno...@gmail.com<javascript:>> 
> wrote: 
> > People tend to think of ADO as only talking to Microsoft databases. 
>  Nothing 
> > could be farther from the truth.  When maintaining adodbapi, I normally 
> test 
> > against MS-SQL Server, Microsoft "Jet" (a.k.a. ACCESS), MySQL, and 
> postgres. 
> > I have also personally used it to get data from IBM DB2, an Active 
> Directory 
> > server, and a .csv file.  If some idiot has written an odbc driver for 
> it, I 
> > will let you read it from Python. 
>
>
> nice. 
>
> does the client run on non-win32 plaforms?  from a cursory read of the 
> website, adodbapi seems to require pywin32. 
>
> -- 
> Javier 
>

Sorry about terse nature of the website information.  I need to repent and 
write better documentation.

ADO is a strictly Microsoft animal. It seems that Microsoft invented ODBC, 
which was quickly recognized as such a great idea that everyone adopted 
it.  So they had to invent something "better", and that was supposed to be 
ADO.  As it happens, the most redeeming feature of ADO is that in runs in 
ODBC mode by default. That having been said, it  is very powerful, and does 
have the ability to reach out to almost any form of tabular data. But it 
does so using COM calls, which are very proprietary.

I have been worrying over the problem of how to read an ADO dataset from 
Linux for years.  I was hoping that IronPython and Mono would provide the 
answer, but it turns out that ADO.NET also uses COM, and looses some of the 
power (like timely update of .rowcount) in the process.  It does not even 
work well in a pure Windows environment. I have abandoned that code fork.  
The open source odbc products leave things to be desired, too, the largest 
being that they only work in ODBC mode and cannot switch to ADO mode when 
the connection string requires it. I have begun to think that eGenix is on 
to something with their "mxODBC connect" product: they use a connection 
server.

Here's how it might be done:  Somewhere, there would have to be a Windows 
box running an ADO connection server program.  Perhaps it could be on the 
actual database server, perhaps not.  A copy of adodbapi which notices that 
it is running where os.name != 'nt' would bring up a link to the connection 
server (using RPC?) which would do the actual data access and pass the 
results back.  A simple server would be trivial to write.  One which worked 
well under a heavy thread load might not be so easy, but my thinking is 
that a heavily used django server which made frequent use of an MSSQL 
database would already be running on a Windows box itself and would not 
need any connection server.

If there is interest, I will start coding a prototype.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to