Skip to Content.
Sympa Menu

freetds - Re: checkins

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: checkins
  • Date: Wed, 5 Jun 2002 10:58:21 -0400


Hi Bill,

> From: Bill Thompson [mailto:thompbil AT exchange.uk.ml.com]
> Sent: June 5, 2002 10:12 AM
>
> I submitted a big patch to brian last week which included the static
> declarations, so I guess he'll find that already done.

I hope so. :)

> As to the dates...several issues...
>
> 1) select getdate(), select convert(smalldatetime, getdate())
>
> I realised that I had forgotten to change function
> convert_datetime4() in
> convert.c to do the date conversions the new way, hence the difference
> between the two columns selected. I've changed this now, so
> both behave
> the same, and the output format is the same, i.e.
>
> Jun 5 2002 02:56:04:226PM
> Jun 5 2002 02:56:00:000PM
>
> I'll send you the patch for this, if you like...

That sounds good. If you post the patch to sourceforge, one of us will
apply it. I'm hoping to work on it this week.

My only complaint, if I may, is that the default default default format,
before locales and/or customization, should emulate the vendors' format,
which is "Jun 5 2002 10:15AM", no seconds or milliseconds (and only one
space between the month and the day, regardless of the number of digits in
the day). I think applications will break otherwise.

I want to make sure I don't sound negative. I'm very happy about this
important bit of work you've done. It's a piece of FreeTDS that really
needed reworking. Sanding off any rough edges is easy by comparison, and
something I'm glad to do.

> 2) the length of the columns
>
> This is down to whatever calls dbconvert() or it's ctlib
> equivalent. in
> dbconvert you pass a "destlen" parameter, which will
> determine the output
> length. In my new code, destlen of -1 means the returned value will be
> trimmed of trailing blanks and null terminated, destlen of -2
> means the
> returned value will not be stripped of trailing blanks, destlen of > 0
> means that the returned value will be padded out if necessary to the
> required length with blanks. I guess we are being passed a
> destlen of 255
> by sqsh...Perhaps I shouldn't pad out with blanks....?

I don't use dbconvert much; I'm more familiar with dbbind. Is the destlen=
-2 an enhancement or a Sybase feature? My MS docs don't show it. How do
you know how many trailing blanks to add?

For destlen >0, we have to pad with blanks and not null-terminate.
Otherwise there's no way for the caller to know where the conversion ends
and garbage begins (trailing blanks are easy to trim if the buffer length is
known). Similarly, for destlen= -1, we have to null-terminate, because
there's no way else to know where the conversion ends.

The sqsh code distinquishes between conversions it does itself and default
conversions. That's all I remember offhand. Thanks for the pointer; that
will make it easier to track down.

Welcome back. June is a good month for taking long breaks.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page