Any news on new MyODBC version?

------=_Part_429_14228199.1134557732960
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

Is there any news on the development of MyODBC? It has been a while since
3.5.12 was released and the update on the hidden server stems from end of
October. Since I am very much hoping for a version in which stored
procedures can return resultsets and of course hoping for version 5.x I am
eager to know if there is any progress. Is there anyone that can shed a
light on this or refer to a location/list/group/webpage where that
information can be found?

Regards,

Frank

PS: please don't see this as a "hurry up" message, it's just the informatio=
n
I am after, even if it is "go to sleep, it'll take at least another N
months" (;-)).

------=_Part_429_14228199.1134557732960--

Re: Any news on new MyODBC version?

On 14/12/05 10:55, Frank Maas wrote:

> Hi,
>
> Is there any news on the development of MyODBC? It has been a while since
> 3.5.12 was released and the update on the hidden server stems from end of
> October. Since I am very much hoping for a version in which stored
> procedures can return resultsets and of course hoping for version 5.x I am
> eager to know if there is any progress. Is there anyone that can shed a
> light on this or refer to a location/list/group/webpage where that
> information can be found?
>
> Regards,
>
> Frank
>
> PS: please don't see this as a "hurry up" message, it's just the information
> I am after, even if it is "go to sleep, it'll take at least another N
> months" (;-)).

Is there any reason why an open source project couldn't fork the MyODBC code
and start fixing the known problems? Or write a new open-source ODBC driver
using the MySQL client API?

I'm just curious!

Cheers,

Chris



--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org

Re: Any news on new MyODBC version?

Chris Ridd wrote:

>Is there any reason why an open source project couldn't fork the MyODBC code
>and start fixing the known problems? Or write a new open-source ODBC driver
>using the MySQL client API?
>
>
Someone's already done a replacement for ADO <=> MyODBC ... have a look
at http://www.vbmysql.com/projects/
But this isn't an ODBC driver - it's just a replacement API that intends
to be an ADO-lookalike.

As for forking MyODBC, I wouldn't bother forking 3.51.x - the MySQL team
have already indicated their general disgust in it, and their intention
to do a complete rewrite. And while that rewrite is being actively
written, the best thing for us to do is sit around and wait for it.

Or if you don't like the speed with which MyODBC-5 is being developed,
you can always simply *participate* in the development of MyODBC. Why do
you need to fork it? Surely if it's not being developed fast enough,
what we need is more *developers*, not more projects.

Lastly, MySQL being a company, they would probably respond to cash
incentives. For example, a group of concerned users could raise $10,000
and say "Hey ... we've got $10,000 that says that MyODBC-5 should be
finished, NOW!". If MyODBC isn't being developed fast enough, then it's
because MySQL don't consider it worthwhile spending any more money on
MyODBC development than they already are. Of course the problem with
this is that they are probably right. Who exactly uses MyODBC anyway?
Some people using MS Access, Excel, etc? I don't think they're exactly
going to be cash cows for MySQL. Most likely most of these users haven't
paid a cent for MySQL ... ever. Maybe there are some kids playing with
IIS and MySQL. Anyway, I would have thought that most businesses that
actually pay for MySQL are using Perl, PHP, or the C API. I'd be very
surprised if anyone was using MyODBC for anything serious. But I may be
wrong ...

--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: dkasak@nusconsulting.com.au
website: http://www.nusconsulting.com.au

--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org

RE: Any news on new MyODBC version?

Daniel,

In the past, I had good success with developing and debugging =
application
programs using the ODBC interface. This allowed me to test on a =
database
such as MS Access and then integrate on site with customers to other
databases. To do this, I had to keep the SQL statements simple so that =
I
didn't run into the problems of database SQL incompatibility. The
advantages which I got from this were that I could plan on using various
database engines.

This was kind of na=EFve on my part but it worked pretty well as long as =
the
tasks I was designing for didn't require use of the database functions =
that
have been implemented differently in the different engines.

However, as I've moved into the more sophisticated tasks, my naivety has
been overcome by the reality of purposeful corporate SQL incompatibility
(they call it extensions). Extensions are fine but not if they defeat =
basic
compatibility The result is that I now have to plan for separate SQL =
for
each engine that I intend to interface to. And, in fact, I have to plan =
as
far as possible for different logic paths for the different engines. =
This
has just about negated the promised, and hoped for, benefits of ODBC.

At this point my opinion is that as long as the SQL is not really a =
standard
in the engine or ODBC driver implementations available, then ODBC is
essentially useless. I converted to VBMySQLDirect, which is both =
language
and database engine unique because of this. The more or less ADO style =
of
interface works fine and I implement separate calls for things like
MoveNext, OpenRecordset, etc. in subroutines or functions.

I get some benefits also: simpler code; faster execution, less complex
structure to understand ...

This is a reversion to the old style of programming (code directed =
rather
than API hiding) but that works fine.

Until the manufacturers of the engines implement all the SQL functions
according to the standard or provide ODBC drivers that convert standard =
SQL
statements to the unique engines constructs, I will have to continue to
implement unique code in my applications for each engine.




Lawson
lawson@vrtinc.com
+1(480)308-0641 (Voice)
+1(602)996-0376 (Fax)
=20

-----Original Message-----
From: Daniel Kasak [mailto:dkasak@nusconsulting.com.au]=20
Sent: Wednesday, December 14, 2005 8:33 PM
To: Chris Ridd; MySQL ODBC
Subject: Re: Any news on new MyODBC version?


Chris Ridd wrote:

>Is there any reason why an open source project couldn't fork the MyODBC
code
>and start fixing the known problems? Or write a new open-source ODBC =
driver
>using the MySQL client API?
> =20
>
Someone's already done a replacement for ADO <=3D> MyODBC ... have a =
look=20
at http://www.vbmysql.com/projects/
But this isn't an ODBC driver - it's just a replacement API that intends =

to be an ADO-lookalike.

As for forking MyODBC, I wouldn't bother forking 3.51.x - the MySQL team =

have already indicated their general disgust in it, and their intention=20
to do a complete rewrite. And while that rewrite is being actively=20
written, the best thing for us to do is sit around and wait for it.

Or if you don't like the speed with which MyODBC-5 is being developed,=20
you can always simply *participate* in the development of MyODBC. Why do =

you need to fork it? Surely if it's not being developed fast enough,=20
what we need is more *developers*, not more projects.

Lastly, MySQL being a company, they would probably respond to cash=20
incentives. For example, a group of concerned users could raise $10,000=20
and say "Hey ... we've got $10,000 that says that MyODBC-5 should be=20
finished, NOW!". If MyODBC isn't being developed fast enough, then it's=20
because MySQL don't consider it worthwhile spending any more money on=20
MyODBC development than they already are. Of course the problem with=20
this is that they are probably right. Who exactly uses MyODBC anyway?=20
Some people using MS Access, Excel, etc? I don't think they're exactly=20
going to be cash cows for MySQL. Most likely most of these users haven't =

paid a cent for MySQL ... ever. Maybe there are some kids playing with=20
IIS and MySQL. Anyway, I would have thought that most businesses that=20
actually pay for MySQL are using Perl, PHP, or the C API. I'd be very=20
surprised if anyone was using MyODBC for anything serious. But I may be=20
wrong ...

--=20
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: dkasak@nusconsulting.com.au
website: http://www.nusconsulting.com.au

--=20
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: =
http://lists.mysql.com/myodbc?unsub=3Dlawson@vrtinc.com


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=3Dgcdmo-myodbc@m.gmane.o rg

Re: Any news on new MyODBC version?

On 15/12/05 3:32, Daniel Kasak wrote:

> Chris Ridd wrote:
>
>> Is there any reason why an open source project couldn't fork the MyODBC code
>> and start fixing the known problems? Or write a new open-source ODBC driver
>> using the MySQL client API?
>>
>>
> Someone's already done a replacement for ADO <=> MyODBC ... have a look
> at http://www.vbmysql.com/projects/
> But this isn't an ODBC driver - it's just a replacement API that intends
> to be an ADO-lookalike.
>
> As for forking MyODBC, I wouldn't bother forking 3.51.x - the MySQL team

Forking from an earlier version might also allow the LGPL to be used with it
again. I know for some people the GPL is a reason to not include the driver
in their product, which is a shame. (No GPL vs LGPL license wars please!)

> have already indicated their general disgust in it, and their intention
> to do a complete rewrite. And while that rewrite is being actively
> written, the best thing for us to do is sit around and wait for it.
>
> Or if you don't like the speed with which MyODBC-5 is being developed,
> you can always simply *participate* in the development of MyODBC. Why do
> you need to fork it? Surely if it's not being developed fast enough,
> what we need is more *developers*, not more projects.

AIUI MySQL has been given a number of patches to MyODBC to fix various
things, and they simply haven't been applied for whatever reason. From
that point of view then, participation isn't working.

[...]
> this is that they are probably right. Who exactly uses MyODBC anyway?
> Some people using MS Access, Excel, etc? I don't think they're exactly
> going to be cash cows for MySQL. Most likely most of these users haven't
> paid a cent for MySQL ... ever. Maybe there are some kids playing with
> IIS and MySQL. Anyway, I would have thought that most businesses that
> actually pay for MySQL are using Perl, PHP, or the C API. I'd be very
> surprised if anyone was using MyODBC for anything serious. But I may be
> wrong ...

You could be right, in which case I'm sort of puzzled why they even bother
with ODBC, or even bothered moving it from the LGPL to the GPL.

Cheers,

Chris



--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org

Re: Any news on new MyODBC version?

Frank Maas wrote:

>Hi,
>
>Is there any news on the development of MyODBC? It has been a while since
>3.5.12 was released and the update on the hidden server stems from end of
>October. Since I am very much hoping for a version in which stored
>procedures can return resultsets and of course hoping for version 5.x I am
>eager to know if there is any progress. Is there anyone that can shed a
>light on this or refer to a location/list/group/webpage where that
>information can be found?
>
>Regards,
>
>Frank
>
>PS: please don't see this as a "hurry up" message, it's just the information
>I am after, even if it is "go to sleep, it'll take at least another N
>months" (;-)).
>
>
>
We are working on a new release for c/odbc v5 at the moment. No date has
been set yet. Hang in there :)

--
Peter Harvey, Software Developer
MySQL AB, www.mysql.com

Are you MySQL certified? www.mysql.com/certification



--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org