Skip to Content.
Sympa Menu

freetds - Re: [freetds] Does SQLBindParameter work with SQLExecDirect

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "David Fraser" <david AT abelon.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Does SQLBindParameter work with SQLExecDirect
  • Date: Fri, 8 Aug 2003 22:33:38 +0100

Thanks guys. I will stick with CVS for now. It certainly solves the
original problem which was my reason for first posting here.
I'm used to working in the release environment you are using, so
am comfortable with that.

And enjoy your holiday James!

David

----- Original Message -----
From: "Lowden, James K" <LowdenJK AT bernstein.com>
To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
Sent: Friday, August 08, 2003 7:05 PM
Subject: RE: [freetds] Does SQLBindParameter work with SQLExecDirect


> > From: David Fraser [mailto:david AT abelon.com]
> > Sent: August 8, 2003 4:19 AM
> >
> > General question - am I mad to run against the 0.62 development
> > code? i.e....
> >
> > Is it relatively stable (with the bonus of bug-fixes and extra
> > functionality making up for any occasional instability)?
> ...
> > OR is this code in major upheaval and not really worth trying to
> > use just yet?
>
> Hi David,
>
> Far from mad, it's probably your best bet, depending on your environment.
>
> Releases are good for people who are running stable code in production
> without problems. Someone who upgrades from one release to another can
> fairly expect his recompiled code to Just Work, provided he makes the
> requisite external changes (e.g., new/different defaults or entries in
> freetds.conf).
>
> My theory is that everything you need to use a release is documented in
the
> release; you don't have to subscribe to this list for that. IMO we've
been
> pretty successful on that score.
>
> Releases get wider use than the snapshots, of course, and sooner or later
> someone shows up here with a bug report. There are three kinds:
>
> 1. We clearly and definitely broke something that used to work.
> 2. It never worked, but is simple to fix in the release.
> 3. Everything else.
>
> The first two types warrant release updates if feasible, which we do
pretty
> much whenever Freddy recommends. They are relatively rare, however,
thanks
> to our, ahem, fanatical testing and inimitable skill! If you were to
> compare 0.61, 0.61.1, and 0.61.2, you'd find only a very few modules and
> something under 100 lines of code changed.
>
> My data-free estimate ;-) is that #3 represents 95% of bug reports
> (excepting pilot error). The first advice for all type 3 problems is
> usually "get yesterday's snapshot". Oftentimes that's enough, because
> whatever it was has already been addressed (because bugs usually lie at
the
> edge of the development envelope). If any any fix or extension is
> developed, it will be based on the current code.
>
> Our CVS code is generally in pretty good shape. It's a rare day that it
> doesn't compile and run the unit tests. Severe breakage is usually
remedied
> quickly.
>
> Because of the way we work, people using a recent snapshot get better
> support, I'd say, than people running the release. But that support comes
> at the price of rather more involvement on their part, in the form of
> reading this list, for instance.
>
> That's my opinion; others will have others, of course.
>
> --jkl
> -----------------------------------------
> The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.
>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>
>






Archive powered by MHonArc 2.6.24.

Top of Page