Skip to Content.
Sympa Menu

freetds - New build warnings; datetime format issue

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: TDS Development Group <freetds AT franklin.metalab.unc.edu>
  • Subject: New build warnings; datetime format issue
  • Date: Tue, 28 May 2002 01:23:21 -0400


All,

I can report cvs builds for me, too. I haven't tested anything yet; I
never test anything more complicated than hot water before breakfast.

My build was perhaps not so clean as others.

$ grep warning make.log |sort|uniq
../../include/config.h:13: warning: this is the location of the previous
definition
/usr/include/netinet/in.h:170: warning: `INADDR_NONE' redefined
bcp.c:1453: warning: previous declaration of `_bcp_start_new_batch'
bcp.c:1535: warning: previous declaration of `_bcp_build_bulk_insert_stmt'
bcp.c:1600: warning: `_bcp_build_bulk_insert_stmt' was declared implicitly
`extern' and later `static'
bcp.c:1698: warning: `_bcp_start_new_batch' was declared implicitly
`extern' and later `static'
bcp.c:1733: warning: previous declaration of `_bcp_send_colmetadata'
bcp.c:1739: warning: `_bcp_send_colmetadata' was declared implicitly
`extern' and later `static'
bcp.c:2389: warning: previous declaration of `_bcp_rtrim_varchar'
bcp.c:2437: warning: `_bcp_rtrim_varchar' was declared implicitly `extern'
and later `static'
convert.c:1212: warning: decimal constant is so large that it is unsigned
convert.c:590: warning: decimal constant is so large that it is unsigned
ct.c:1353: warning: assignment makes pointer from integer without a cast
dblib.c:1847: warning: decimal constant is so large that it is unsigned
dblib.c:1876: warning: previous declaration of `days_this_year'
dblib.c:1938: warning: `days_this_year' was declared implicitly `extern'
and later `static'

OK, well, I did a little testing before breakfast, in my decaffeinated
state, against Adaptive Server Enterprise/11.9.2.3/1159/P/SWR 9223 ESD
3/Linux Intel:

[8] sandbox.master.1> select convert(varchar(30), convert(datetime,
'1/1/1800')) as OnceUponaTime
[8] sandbox.master.2> select convert(datetime, '1/1/1800') as ByFreeTDS
[8] sandbox.master.3> go
OnceUponaTime
------------------------------
Jan 1 1800 12:00AM

(1 row affected)

ByFreeTDS




------------------------------------------------------------------------
-------------------------------------------------------------------------
-------

Jan 1 1800 12:00:00:000AM


(1 row affected)

Observations:

1. The output format is different; I don't think it should be.
2. The datatype is not what I expected. Is that FreeTDS or sqsh creating
a varchar(255) for a date string? The same output on Sybase's isql is
much more readable, and the format is consistent:

1> select convert(varchar(30), convert(datetime, '1/1/1800')) as
OnceUponaTime
2> select convert(datetime, '1/1/1800') as ByFreeTDS
3> go
OnceUponaTime
------------------------------
Jan 1 1800 12:00AM

(1 row affected)
ByFreeTDS
--------------------------
Jan 1 1800 12:00AM

(1 row affected)

Before I go any further, I guess I should install sqsh on the linux box
(linked to Sybase's libraries) to give me apples2apples. But we *do* want
item-for-item faithful reimplementation of Sybase's libraries, yes? If
so, the default datetime->string conversion should exclude seconds and
milliseconds.

Off to breakfast.

Regards,
--jkl




Archive powered by MHonArc 2.6.24.

Top of Page