freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
Re: [freetds] RE : RE : location of config parameter?
- From: <loic.cloatre AT orange.com>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] RE : RE : location of config parameter?
- Date: Thu, 29 Dec 2011 09:16:49 +0100
Hi,
I have tested your modification and it works for my Sybase 15.0.2:
static const unsigned char defaultcaps[] = {
/* type, len, data, data, data, data, data, data, data, data, data (9
bytes) */
0x01, 0x0c, 0x07 ,0xcd, 0xff, 0x00, 0x08, 0x0E, 0x6D, 0x7F, 0xFF, 0xFF,
0xFF, 0xFE,
0x02, 0x09, 0x00, 0x00, 0x00, 0x00, 0x02, 0x68, 0x00, 0x00, 0x00
};
I see bytes in the log file (from row 0040, column 11:01 0c)
net.c:741:Sending packet
0000 02 01 00 64 00 00 00 00-00 00 00 00 00 00 0a 00 |...d.... ........|
0010 00 00 00 00 00 00 00 00-00 00 00 00 00 69 73 6f |........ .....iso|
0020 5f 31 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |_1...... ........|
0030 00 00 00 00 00 00 00 00-00 00 00 05 01 35 31 32 |........ .....512|
0040 00 00 00 03 00 00 00 00-e2 19 00 01 0c 07 cd ff |........ ........|
0050 00 08 0e 6d 7f ff ff ff-fe 02 09 00 00 00 00 02 |...m.... ........|
0060 68 00 00 00 - |h...|
The only question of my boss is "why 0x07 ,0xcd, 0xff?"
I have tested with only bit 83 set to 1 and it does not work:
maybe the other bits of 0x07 ,0xcd, 0xff are default Sybase value?
Loic
-----Message d'origine-----
De : freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] De la part de Ludo Brands
Envoyé : lundi 19 décembre 2011 14:08
À : 'FreeTDS Development Group'
Objet : [freetds] RE : RE : location of config parameter?
> > I have no problems sharing the changes I made.
>
> Thank you for that offer, Ludo.
>
> > - since this is a sybase only extension, I assume the
> > TDS_REQ_LARGEIDENT capability request should be set only for recent
> > Sybase servers, based on the existence of the SYBECAPTYP
> error. What
> > are the possibilities?
>
> I see no need to worry about capacity negotiation with old Sybase
> servers.
>
> >From the design of the packet and Sybase's track record, I bet old
> servers simply ignore (or acknowledge in the negative) capacity
> requests they don't recognize. If you're a server that supports 65
> capacity bits and I'm a client asking for #83, you can easily and
> safely say No.
>
> If someone reading this message knows of a new Sybase client that
> cannot connect to an old Sybase server (that supports TDS 5.0), that
> would certainly be evidence to the contrary.
>
> Absent that evidence, we can at least start with no switch.
> That has the advantage of simplicity and of expoiting new servers,
> which is, er, the way of the future.
>
> Regarding ENABLE_EXTRA_CHECKS, I would remove outdated code from
> compilation until someone gets around to updating it. Just put
>
> # if CAPACITY_8_BYTES
>
> around the obsolete validation for now. If you want to fix the
> validation instead, that's fine, too.
>
Attached the patch.
"# if CAPACITY_8_BYTES" is put around the body of "static void
tds_capability_test(void)" to make mods limited to mem.c. I wasn't able to
test with ENABLE_EXTRA_CHECKS 1 because of missing functions such as
tds_check_tds_extra (windows).
Ludo
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this
message was modified, changed or falsified.
Thank you.
-
Re: [freetds] location of config parameter?
, (continued)
-
Re: [freetds] location of config parameter?,
James K. Lowden, 12/15/2011
- Re: [freetds] location of config parameter?, loic.cloatre, 12/16/2011
-
Re: [freetds] location of config parameter?,
Thompson, William, 12/16/2011
-
Re: [freetds] location of config parameter?,
loic.cloatre, 12/16/2011
- Re: [freetds] location of config parameter?, LacaK, 12/16/2011
-
Re: [freetds] location of config parameter?,
jklowden, 12/16/2011
-
Re: [freetds] location of config parameter?,
James K. Lowden, 12/17/2011
-
[freetds] RE : location of config parameter?,
Ludo Brands, 12/18/2011
-
Re: [freetds] RE : location of config parameter?,
James K. Lowden, 12/18/2011
- [freetds] RE : RE : location of config parameter?, Ludo Brands, 12/19/2011
- Re: [freetds] RE : RE : location of config parameter?, loic.cloatre, 12/29/2011
- [freetds] RE : RE : RE : location of config parameter?, Ludo Brands, 12/29/2011
-
Re: [freetds] RE : location of config parameter?,
James K. Lowden, 12/18/2011
- [freetds] apache rpm generation, loic.cloatre, 12/28/2011
- Re: [freetds] apache rpm generation, James K. Lowden, 12/28/2011
-
[freetds] RE : location of config parameter?,
Ludo Brands, 12/18/2011
-
Re: [freetds] location of config parameter?,
James K. Lowden, 12/17/2011
- Re: [freetds] RE : location of config parameter?, loic.cloatre, 12/19/2011
-
Re: [freetds] location of config parameter?,
loic.cloatre, 12/16/2011
-
Re: [freetds] location of config parameter?,
James K. Lowden, 12/15/2011
Archive powered by MHonArc 2.6.24.