FreeTDS Development Group

[Gregg Jensen <greggj AT savvis.net>]

tetherow AT nol.org wrote:

>
>
> When you untar the package, does it include a .deps directory anywhere?
> If it does you need to remove it.  As for the endian-ness we haven't
> checked it since the last round that kevin replied to but it was
> working then.

Yep. .deps exists and removing it made the make continue. BUT, it seems this 
configure
also produces HW_LITTLE_ENDIAN also.

>
>
> ... but I sure wouldn't want to try it out
> > on Sybase.  I have been told, (ahem...by the database administrator) that 
> > it causes
> > a stack trace to occur and can bring down (or as a result, needs to bring 
> > down) the
> > database.
>
> I can't image how you could bring down a database with the wrong
> endian-ness (not saying it is the case, but that it just baffles me
> that someone could write a DB server that allows that kind of
> misbehaviour :)  It still bothers me that sybase/MS didn't use network
> byte order for sending stuff across the network anyway.
>

I am told it doesn't really bring it down, but in the process of causing a 
stack trace,
that it (potentially) puts the database in a "unstable state in which data 
can be lost
and not recoverable".

Sam, weren't you doing some real stuff with this library on Solaris (Sparc?)? 
 I
was wondering if you had experienced any problems with the new stuff?  I
have compiled the latest into sqsh-1.4 and it either doesn't like time/date 
or int4
columns, because sqsh core dumps while trying to print out these two columns 
side
by side. (ie, I am not sure if its a problem with time/date of int4 or 
something else).
It almost seems like it doesn't parse the token properly.  But, the same code 
on
Linux (Intel) parses just fine.  Have you (or anyone else) experienced 
anything
similar?

Gregg