Re: CS_SERVERADDR tag is not handled correctly in ct_con_props

2014/1/6 Stephen Marshall <[email protected]>:
> Let me try to explain in better detail:
>
> Problem:
> The CS_SERVERADDR enum is not properly honored in the ct_con_props function
> call.
> For example, this call should effectively set the host and port for a DB
> connection, but it results in an error when the connection information is
> actually used.
>     ct_con_props( g_connection,
>                       CS_SET,
>                       CS_SERVERADDR,
>                       (CS_VOID*)server,
>                       CS_NULLTERM,
>                       (CS_INT*)NULL
>                     );
> Here: g_connection is a pointer to type CS_CONNECTION, and server is text
> of the form "<host> <port>".  Note that FreeTDS provides other ways to
> specify host and port (e.g. setting the server parameter to
> "<host>:<port>"; however, the method using CS_SERVERADDR does not work.
>

Now I got it.

> Approaches to fix:
> I see two ways to attack this problem.  Of course, you may see others.
>
> One approach is to ensure port information is set in the CS_CONNECTION data
> structures and then passed to the other internal data structures used to
> establish a connection in FreeTDS.  This would be a true fix to the
> problem, but would require some changes to at least a few internal data
> structures.
>
> Another approach is the mark the CS_SERVERADDR tag as disabled in FreeTDS.
>  This would not actually fix the problem, but would allow client
> applications to work around the limitation.  However, I think this can be
> achieved by simply undefining CS_SERVERADDR in cspublic.h.
>
> If you have any thoughts on ways to fix this, I'm certainly open to
> suggestions.
>
> Steve
>

Well, as Sybase write specification while we should stick to it we
should just handle properly this tag. Perhaps the problem is how to
fit this with other port specification. Should CS_SERVERADDR port
override CS_SERVERNAME "host:port" FreeTDS syntax? Perhaps we should
just document the combination as not supported or undefined behaviour.

Frediano