By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,207 Members | 1,028 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,207 IT Pros & Developers. It's quick & easy.

mx odbc

P: n/a
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

Jul 18 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
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
Jul 18 '05 #2

P: n/a
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
Jul 18 '05 #3

P: n/a
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).


Jul 18 '05 #4

P: n/a
"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).
Jul 18 '05 #5

P: n/a
Kim Petersen <kp@kyborg.dk> 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
Jul 18 '05 #6

P: n/a
David Bolen wrote:
Kim Petersen <kp@kyborg.dk> 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

Jul 18 '05 #7

P: n/a
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.


Jul 18 '05 #8

P: n/a
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
Jul 18 '05 #9

P: n/a
Alan Kennedy <al****@hotmail.com> wrote in message news:<3F***************@hotmail.com>...

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
Jul 18 '05 #10

P: n/a
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

Jul 18 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.