Extend API with validate function for connection string

[yaitskov]

Hi,

__parse_connection_string is a private function of SQLDriverConnect. In my app there is a validation command which verifies a project file, without an attempt of connecting to DB, and ODBC connection string is part of the file.

How about to expose that function through some public API method e.g.

SQLRETURN SQLDriverValidateConnectionSyntax(SQLCHAR  *conn_str_in);

[lurcher]

On 20/11/2022 22:27, Daneel S. Yaitskov wrote:

Hi,

|__parse_connection_string| is a private function of |SQLDriverConnect|. In my app there is a validation command which verifies project file and ODBC connection string is part of the file.

How about to expose that function through some public API method e.g.

|SQLRETURN SQLDriverValidateConnectionSyntax(SQLCHAR *conn_str_in); |

— Reply to this email directly, view it on GitHub https://github.com/lurcher/unixODBC/issues/124, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62KMFMM7G6CAXAB5NUDWJKQUXANCNFSM6AAAAAASGB4HNI. You are receiving this because you are subscribed to this thread.Message ID: @.***>

Nice idea, but not sure of the slope we would be starting down and how slippery it was if we started adding to the published (not by unixODBC) API.

[yaitskov]

Many standard features start as vendor specific ones.
Is there standard on connection string syntax?

[lurcher]

On 21/11/2022 14:43, Daneel S. Yaitskov wrote:

Many standard features start as vendor specific ones. Is there standard on connection string syntax?

Yes, though I don't have it to hand. But I would question if unixODBC falls within the role of a vendor WRT Microsoft and the ODBC Spec. There are enough ODBC Driver writing companies who (IMHO) add to the standard for marketing reasons already.

I guess the question would be what actual utility that is provided by adding a function to check the validity of the syntax that isn't already present in SQLDriverConnect. It will still eventually come down to what the actual driver regards as valid despite what the standard says. And a function in the DM won't know what a particular driver does or doesn't support.

[yaitskov]

I think I have a workaround - connect to closed port - if error is closed port then connection string might be good or connect to dumb open port - once TCP connection is accepted (use source ip/port to distinguish calls) - then ok

[lurcher]

On 21/11/2022 15:29, Daneel S. Yaitskov wrote:

I think I have a workaround - connect to closed port - if error is closed port then connection string might be good or connect to dumb open port - once TCP connection is accepted (use source ip/port to distinguish calls) - then ok

That assumes the driver communicates with a port, many don't

[yaitskov]

https://github.com/lurcher/unixODBC/issues/125