mx odbc

Discussion in 'Python' started by Kim Petersen, Jul 8, 2003.

  1. Kim Petersen

    Kim Petersen Guest

    Regarding ODBC usage in Python...

    it seems to me that there is a couple of ways to use odbc from python,
    one of these is the MX version - now that one has a pretty steep licence
    cost (imho). So now comes my question (from reading this group quite a bit):

    - what is the basic reason for using MX versus the others?
    - why do you (newsgroup) seem to think that this package is
    the preferred one?
    - in case above is incorrect - what package is preferred?

    Note: i have nothing against paying for commercial products - but 75$'s
    for a cpu licence (customer) or >1000$ for a developer single cpu, seems
    to me to be a bit too steep, for a thing thats basically a requirement
    for windows programming....

    --
    Med Venlig Hilsen / Regards

    Kim Petersen - Kyborg A/S (Udvikling)
    IT - Innovationshuset
    Havneparken 2
    7100 Vejle
    Tlf. +4576408183 || Fax. +4576408188
     
    Kim Petersen, Jul 8, 2003
    #1
    1. Advertising

  2. Kim Petersen wrote:
    > Regarding ODBC usage in Python...
    >
    > it seems to me that there is a couple of ways to use odbc from python,
    > one of these is the MX version - now that one has a pretty steep licence
    > cost (imho). So now comes my question (from reading this group quite a
    > bit):
    >
    > - what is the basic reason for using MX versus the others?


    Having a maintained and actively supported ODBC interface which
    works on all major platforms, not just Windows ?!

    --
    Marc-Andre Lemburg
    eGenix.com

    Professional Python Software directly from the Source (#1, Jul 08 2003)
    >>> Python/Zope Products & Consulting ... http://www.egenix.com/
    >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

    ________________________________________________________________________
    2003-07-01: Released mxODBC.Zope.DA for FreeBSD 1.0.6 beta 1
     
    M.-A. Lemburg, Jul 8, 2003
    #2
    1. Advertising

  3. Kim Petersen

    trewornan Guest

    On Tue, 08 Jul 2003 18:04:11 +0200, M.-A. Lemburg wrote:

    > Having a maintained and actively supported ODBC interface which
    > works on all major platforms, not just Windows ?!


    Agreed that this must be a lot of work but most of us use open source
    software for a reason. Certainly the licensing of mxODBC was the main
    reason I choose to use the mySQL module directly instead.

    Trewornan
     
    trewornan, Jul 8, 2003
    #3
  4. Kim Petersen

    Kim Petersen Guest

    M.-A. Lemburg wrote:
    > Kim Petersen wrote:
    >
    >> Regarding ODBC usage in Python...
    >>
    >> it seems to me that there is a couple of ways to use odbc from python,
    >> one of these is the MX version - now that one has a pretty steep
    >> licence cost (imho). So now comes my question (from reading this group
    >> quite a bit):
    >>
    >> - what is the basic reason for using MX versus the others?

    >
    >
    > Having a maintained and actively supported ODBC interface which
    > works on all major platforms, not just Windows ?!


    I'm not arguing that thats not important - *but* paying 70$ pr.
    customer, is the equivalent of paying you for 1hr of support for each
    customer [not installation mind you], where our own licence/supportcost
    is already getting lower and lower... I find that _extremely_ steep - i
    could and would accept such a cost for the python platform (no trouble!)
    [except in the few (from our view) cases where the user just needs a
    small tool.

    IMHO your setting the value of the package so high, that there would be
    better economics in making a rewrite of our database modules every time
    a customer needs some new one (porting to a new database specific DB-SIG
    compliant module).

    >
     
    Kim Petersen, Jul 9, 2003
    #4
  5. Kim Petersen

    Paul Boddie Guest

    "trewornan" <galen@grex_nospam_.org> wrote in message news:<pan.2003.07.08.21.08.42.395562@grex_nospam_.org>...
    > On Tue, 08 Jul 2003 18:04:11 +0200, M.-A. Lemburg wrote:
    >
    > > Having a maintained and actively supported ODBC interface which
    > > works on all major platforms, not just Windows ?!

    >
    > Agreed that this must be a lot of work but most of us use open source
    > software for a reason.


    Yes, mostly for access to the sources, the possibility of
    redistribution and the various other freedoms associated with Open
    Source/Free Software.

    Paul

    P.S. Of course it doesn't hurt to get stuff for free, but if that was
    the most important thing, you'd surely be content to download
    proprietary "free stuff", demos and evaluations (and be at the mercy
    of the binary-only distributor in question).
     
    Paul Boddie, Jul 9, 2003
    #5
  6. Kim Petersen

    David Bolen Guest

    Kim Petersen <> writes:

    > I'm not arguing that thats not important - *but* paying 70$
    > pr. customer, is the equivalent of paying you for 1hr of support for
    > each customer [not installation mind you], where our own
    > licence/supportcost is already getting lower and lower... I find that
    > _extremely_ steep - i could and would accept such a cost for the
    > python platform (no trouble!) [except in the few (from our view) cases
    > where the user just needs a small tool.


    Except that if you're going to resell a product, presumably you'd go
    for the per-developer fee ($1250). It'll beat the per-CPU license at
    about 18 customers (assuming one CPU per customer), and just continue
    shrinking on a per-customer basis after that. In effect, the
    per-developer license is a one time, royalty free, license, the
    marginal unit cost of which disappears over time. As with anything,
    the actual price is up to the owner to set, but on our part, we've
    found the economics reasonable for the functionality supplied within
    our commercial endeavors.

    Is it the only way to go for database access with Python - certainly
    not. But for us (Windows platform with ODBC sources) its worth it for
    the effort Marc-Andre has put in to best support ODBC in that
    environment.

    Just another data point for what it's worth.

    -- David
     
    David Bolen, Jul 9, 2003
    #6
  7. Kim Petersen

    Kim Petersen Guest

    David Bolen wrote:
    > Kim Petersen <> writes:
    >
    >
    >>I'm not arguing that thats not important - *but* paying 70$
    >>pr. customer, is the equivalent of paying you for 1hr of support for
    >>each customer [not installation mind you], where our own
    >>licence/supportcost is already getting lower and lower... I find that
    >>_extremely_ steep - i could and would accept such a cost for the
    >>python platform (no trouble!) [except in the few (from our view) cases
    >>where the user just needs a small tool.

    >
    >
    > Except that if you're going to resell a product, presumably you'd go
    > for the per-developer fee ($1250).

    We work in teams - so that would be 1250*4 making the below calculation
    18*4 (and we're not able to pull in freelancers on this kinda stuff then
    - other than paying another 1250). [Note: i'm being honest to the gist
    of the licence here - you could argue for one developer fee, rest of the
    developers run pr.CPU licence, and you build project on the developer
    machine for final wrapping]

    > It'll beat the per-CPU license at
    > about 18 customers (assuming one CPU per customer), and just continue
    > shrinking on a per-customer basis after that. In effect, the
    > per-developer license is a one time, royalty free, license, the
    > marginal unit cost of which disappears over time. As with anything,
    > the actual price is up to the owner to set, but on our part, we've
    > found the economics reasonable for the functionality supplied within
    > our commercial endeavors.
    >
    > Is it the only way to go for database access with Python - certainly
    > not. But for us (Windows platform with ODBC sources) its worth it for
    > the effort Marc-Andre has put in to best support ODBC in that
    > environment.


    Not arguing about Marc-Andre's fine contributions - they are excellent ;-)
    I have no idea about the support (obviously) - but then i hardly ever
    buy/use support for development tools [especially not open-source ones].

    >
    > Just another data point for what it's worth.
    >
    > -- David



    --
    Med Venlig Hilsen / Regards

    Kim Petersen - Kyborg A/S (Udvikling)
    IT - Innovationshuset
    Havneparken 2
    7100 Vejle
    Tlf. +4576408183 || Fax. +4576408188
     
    Kim Petersen, Jul 10, 2003
    #7
  8. Kim Petersen

    Kim Petersen Guest

    Alan Kennedy wrote:
    > Kim Petersen wrote:
    >
    >
    >>I have no idea about the support (obviously) - but then i hardly ever
    >>buy/use support for development tools [especially not open-source ones].

    >
    >
    > Well, that just about says it all for the theory that "open source
    > developers should make their money from services".
    >
    > What many people seem to forget is that maintaining high quality
    > software *is* a service: in the case of mxODBC, a very high quality
    > service. If M-A-L didn't charge licensing fees, then he'd be providing
    > a high quality service, i.e. well designed, maintained and up-to-date
    > software, without any income at all, since, in general, developers
    > don't buy support for development tools, unless they absolutely must.


    It *is* a service - i agree completely and even if i don't use the
    support i'll prolly patch the problem and send the result upstream -
    that really isn't an argument to use in the below. The reason for that
    statement was simply that in opensource situations, we'll _maybe_ locate
    the bug ourselves (or patch the product to do what we want - which
    *cannot* be done in closed-source) and i'm not talking beer!

    >
    > Kim Petersen wrote:
    >
    >
    >>[snip] paying 70$ pr.
    >>customer, is the equivalent of paying you for 1hr of support for each
    >>customer [not installation mind you], where our own licence/supportcost
    >>is already getting lower and lower

    >
    >
    > It's a free market: pick another (cheaper) ODBC driver and use that
    > instead. Just make sure that your customers understand that they will
    > get a poorer quality product from you because they're paying you less
    > money, so you have to use lower quality components in your software:
    > I wonder how long they'll be your customers.


    Regarding the free marked - i agree - against the other - what is it
    *exactly* that makes mxODBC a better quality product - noone has seemed
    to be able to tell (and yes - you do in the above claim that...). So i
    can't even tell my customers that [even if i believed that your argument
    of telling customers about developing methods have any substance for
    them *at all* (its the product that counts - not the methods)].

    >
    > Kim Petersen wrote:
    >
    >
    >>We work in teams - so that would be 1250*4 making the below calculation
    >>18*4 (and we're not able to pull in freelancers on this kinda stuff then
    >>- other than paying another 1250).

    >
    >
    > And how much would you pay these freelancers? Probably quite a
    > substantial amount over the weeks or months that you retain them,
    > and probably *far* in excess of the developer license cost for mxODBC.
    > How much improved productivity will you get from those developers
    > because they're not spending a week chasing weird bugs in the
    > database/ODBC code?


    essence of my argument - the pricing of this *little* (but essential)
    component drives the pricing of the end-product up a substantial amount
    - that imho is not corresponding to the usefulnes of the product. [and
    to use your argument from before - i need to find another product then].

    >
    > I feel quite annoyed when people give out about having to pay money
    > for software: someone, somewhere has to write that software: that
    > someone has to pay the rent, the utility bills, etc, etc, etc, etc.
    > Demanding that everyone work for nothing is completely unreasonable:
    > just because you're too stingy to pay for what you get. Some OSS
    > developers are fortunate enough that they don't have to charge money
    > for their software, because the government, or the education system,
    > or some charitable foundation, pays their wages. But that's not true
    > for all OSS developers.


    We already pay substantial amounts for software - including donations
    for opensource projects - so your tirade falls on a wrong spot. [In our
    endsystems i estimate around 60% goes to hardware 30% goes to royalties
    etc. (as we implement in OSS software a large amount of this returns -
    not as much as i would wish - but then thats something for my boss to
    decide)].

    >
    > To those who continue to complain about having to pay for software,
    > I say: If you don't like paying, fork the software, maintain your
    > own product and let it be free (both in the free-speech and the
    > free-beer senses): see how you long *you* last.


    Can you mention even on spot where i complained against paying for
    software ? (hint: the amount - not that it has a price).

    TANSTAAFL!
    >
    > not-biting-the-hand-that-feeds-ly yrs.
    >
     
    Kim Petersen, Jul 10, 2003
    #8
  9. Kim Petersen

    Alan Kennedy Guest

    Kim Petersen wrote:

    > It *is* a service - i agree completely and even if i don't use the
    > support i'll prolly patch the problem and send the result upstream -
    > that really isn't an argument to use in the below. The reason for
    > that statement was simply that in opensource situations, we'll
    > _maybe_ locate the bug ourselves (or patch the product to do what
    > we want - which *cannot* be done in closed-source) and i'm not
    > talking beer!


    I agree that it's a good thing that you can find and patch bugs
    yourself, because it's open source. But I do feel compelled to point
    out that if the patch is to be accepted back into the product, that
    requires time from the maintainer, to review your patch, and test it
    in all scenarios and on all platforms. I'm sure you appreciate this,
    but I think a lot of people don't.

    > Regarding the free marked - i agree - against the other - what is it
    > *exactly* that makes mxODBC a better quality product - noone has
    > seemed to be able to tell (and yes - you do in the above claim that...).


    Hmm, I'm not sure I get what you're trying to say here: what do you
    mean by "noone has seemed to be able to tell"? If by that you mean
    "what is it that makes mxODBC a better quality product", try the
    following

    1. Continually kept up to date with all versions of python
    2. Continually kept up to date with all versions of ODBC standards
    3. Continually maintained on a wide variety of platforms
    4. Optimal memory and time efficiency because it's mostly coded in C
    5. Etc, etc.

    If these aren't the kinds of things that make software "better
    quality", then I have no idea what you mean.

    > So i
    > can't even tell my customers that [even if i believed that your
    > argument of telling customers about developing methods have any
    > substance for them *at all* (its the product that counts - not
    > the methods)].


    No, it's the method that counts when you're talking about the cost of
    development. You complained about how expensive a developer license
    for mxODBC was, which is your methods, not your products.

    Let's try a simple little thought experiment. Say you hire a
    freelancer, and you pay them €1000/week to work on your product. You
    hire them for 6 months, or 26 weeks, so that's €26,000 that pay your
    freelancer.

    Now say you get a nasty little bug, that requires detailed
    investigation. You're fortunate enough to have a quality freelancer
    that is able to find the bug, after 3-4 days of investigation, fix
    the bug in 2 days, and then test the fix for another 2 days. So that's
    7-8 days, @€200/day. And that's just one bug.

    Seems to me that the cost of your software "developer" licenses are
    actually quite cost effective after all.

    > essence of my argument - the pricing of this *little* (but
    > essential) component drives the pricing of the end-product up
    > a substantial amount - that imho is not corresponding to the
    > usefulnes of the product.[and to use your argument from before -
    > i need to find another product then].


    No, you're thinking about it all wrong.

    This little component, an ODBC driver, *does* correspond to the
    "usefulness" (i.e. quality) of the product. Or more correctly, if
    one is using a poor quality ODBC driver, then that contributes to
    the "uselessness" of one's product.

    > Can you mention even on spot where i complained against paying for
    > software ? (hint: the amount - not that it has a price).


    Kim Petersen wrote:

    > I'm not arguing that thats not important - *but* paying 70$ pr.
    > customer, is the equivalent of paying you for 1hr of support for
    > each customer [not installation mind you], where our own
    > licence/supportcost is already getting lower and lower... I find
    > that _extremely_ steep


    Fair enough, it was the amount you complained about, not that there
    was a cost. But is $70 really such a high cost? What percentage of the
    end-user cost of your product is required to pay for mxODBC?

    > TANSTAAFL!


    I think we definitely agree on that.

    --
    alan kennedy
    -----------------------------------------------------
    check http headers here: http://xhaus.com/headers
    email alan: http://xhaus.com/mailto/alan
     
    Alan Kennedy, Jul 10, 2003
    #9
  10. Kim Petersen

    Paul Boddie Guest

    Alan Kennedy <> wrote in message news:<>...
    >
    > To those who continue to complain about having to pay for software,
    > I say: If you don't like paying, fork the software, maintain your
    > own product and let it be free (both in the free-speech and the
    > free-beer senses): see how you long *you* last.


    Or in this case, don't fork the product because the licence won't
    permit it. Instead, write your own ODBC driver manager package.

    I've stated before that vocal critics of mxODBC's licensing could
    relatively easily wrap something like iODBC and release the results
    under an open source licence, but the fact that it hasn't been done
    really says a lot about how much the mxODBC licensing is a "problem"
    for those people.

    Paul
     
    Paul Boddie, Jul 10, 2003
    #10
  11. Kim Petersen

    Kim Petersen Guest

    Alan Kennedy wrote:
    > Kim Petersen wrote:
    >>Regarding the free marked - i agree - against the other - what is it
    >>*exactly* that makes mxODBC a better quality product - noone has
    >>seemed to be able to tell (and yes - you do in the above claim that...).

    >
    >
    > Hmm, I'm not sure I get what you're trying to say here: what do you
    > mean by "noone has seemed to be able to tell"? If by that you mean
    > "what is it that makes mxODBC a better quality product", try the
    > following
    >
    > 1. Continually kept up to date with all versions of python
    > 2. Continually kept up to date with all versions of ODBC standards
    > 3. Continually maintained on a wide variety of platforms
    > 4. Optimal memory and time efficiency because it's mostly coded in C
    > 5. Etc, etc.
    >
    > If these aren't the kinds of things that make software "better
    > quality", then I have no idea what you mean.


    Those qualities are all general product qualities, and may or may not
    have effect for your development. [hmm - i'm having a hard time
    formulating this in english - sorry if it gets out mangled]. A thing
    like: the type conversion (to and from) the SQL backend is highly
    efficient - would be a quality in my eyes.

    In the world where i live, the platforms are fixed and tested for the
    software [eg. specific versions (Windows, Linux and SCO (urgh!))],
    memory and time efficiencies may have influence but generally don't (one
    of the reasons we use python btw. otherwise we'd stick with C/C++ or
    Delphi). If a customer upgrade's a system to something not recommended -
    well the trouble will come knocking on his wallet and be a welcome guest
    in ours.

    >
    >>essence of my argument - the pricing of this *little* (but
    >>essential) component drives the pricing of the end-product up
    >>a substantial amount - that imho is not corresponding to the
    >>usefulnes of the product.[and to use your argument from before -
    >>i need to find another product then].

    >
    >
    > No, you're thinking about it all wrong.
    >
    > This little component, an ODBC driver, *does* correspond to the
    > "usefulness" (i.e. quality) of the product. Or more correctly, if
    > one is using a poor quality ODBC driver, then that contributes to
    > the "uselessness" of one's product.
    >


    Let me rephrase the part about why i find the pricing steep:

    1 developer licence for Qt: 1550$
    1 developer licence for mxODBC: 1025$

    from my point of view - there _should_ be a correspondance between
    problem-domain and pricing.

    >
    >>Can you mention even on spot where i complained against paying for
    >>software ? (hint: the amount - not that it has a price).

    >
    >
    > Kim Petersen wrote:
    >
    >
    >>I'm not arguing that thats not important - *but* paying 70$ pr.
    >>customer, is the equivalent of paying you for 1hr of support for
    >>each customer [not installation mind you], where our own
    >>licence/supportcost is already getting lower and lower... I find
    >>that _extremely_ steep

    >
    >
    > Fair enough, it was the amount you complained about, not that there
    > was a cost. But is $70 really such a high cost? What percentage of the
    > end-user cost of your product is required to pay for mxODBC?


    That certainly depends on the product - if we run our full economics
    package for the customer - it would be negligible. If we're talking
    about a small contactdatabase (or a minor statistics module to run on a
    single desktop) - it certainly is substantial.

    --
    Med Venlig Hilsen / Regards

    Kim Petersen - Kyborg A/S (Udvikling)
    IT - Innovationshuset
    Havneparken 2
    7100 Vejle
    Tlf. +4576408183 || Fax. +4576408188
     
    Kim Petersen, Jul 10, 2003
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lupina

    Create Access File through ODBC

    Lupina, Apr 29, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    578
    Jim Hughes
    May 5, 2004
  2. Michael

    DBI ODBC

    Michael, Jan 6, 2004, in forum: Perl
    Replies:
    1
    Views:
    833
    Michael
    Jan 6, 2004
  3. Robert Brown
    Replies:
    2
    Views:
    430
    Kevin Spencer
    Jul 3, 2003
  4. Giuseppe D'Elia

    Error with ASP.NET opening OleDb/ODBC database

    Giuseppe D'Elia, Jul 15, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    1,496
    John Toop
    Jul 25, 2003
  5. Wes Gamble
    Replies:
    1
    Views:
    183
    Gerardo Santana Gómez Garrido
    Apr 5, 2006
Loading...

Share This Page