Vista - SQL connection string encoded in a Uri?

I've been looking for an established way to encode a connection string into a
Uri. Uri's are used for file access using File://path. Has anyone seen a
Sql://server/db/table?query approach?

Thanks

Lou wrote:Sure, JDBC uses this method -- not URIs, precisely, but syntax that
resembles them. For example, a connection string for SQL Server using the
jTDS driver looks like this:

jdbc:jtds:sqlserver://<server>\<instance>:<port>/<database>

The question is, why would you want to do this for .NET connection strings?
Those have an established format too, it just doesn't resemble a URI. The
general format is just simple key=value pairs, separated by semicolons:

Provider=<provider>;<param>=<value>;...

There's any number of ways you can stuff this in a URI, but you'll have to
roll your own mechanism for encoding and decoding them (the Uri class is
only of limited help here). But again, why would you? Is there some place
you can store URIs but not general strings?

Note that it's a very bad idea to allow arbitrary queries and pass those
around as URIs, for reasons I hopefully don't have to elaborate. You may
want to look at a REST approach to resources instead, but without tying
those to specific database tables. Take a look at ADO.NET Data Services, for
example: http://msdn.microsoft.com/data/bb931106

--
J.

Jeroen,

Thanks, so I'm not crazy. What I'm after here is a way to store a location
for a data source or sink. I want to keep a uniform link for ANY source or
sink. Why should there be a way to connect to a web site/FTP/Mail/File etc
and not have a way to use that same Uri (emphasis on Universal) without
someway of including SQL in the mix?

I'm prepared to 'roll my own' on this. It's an internal thing. I suppose
since most SQL server access is managed intermurrally having a URI wouldn't
provide universal access but I'm looking for consistency of declaration.
Otherwise I'd have to check to see if the string was a connection string or a
URI. Not so terrible I guess but not quite esthetic. :-)

Lou

"Jeroen Mostert" wrote:

Lou wrote:The big impedance mismatch I see is that URIs (Uniform Resource Identifiers)
are meant to uniquely label things, often more specifically by use of a
location (the ever popular URLs). What they're not good at is additionally
embedding the format of the thing you're labeling, and they're almost never
used for that.

For example, http://www.microsoft.com describes a resource accessed through
the HTTP protocol, but it doesn't tell you anything about HTML -- that's
outside the scope. Similarly, an sql:// URI could specify a table in a
database on a server, but it's not natural to use it to describe the table's
structure as well.

So you could use URIs for the sources and destinations of the messages as
you describe them, but you would need to lay down the format of those
messages quite rigidly, or a way to figure out the format for each URI
scheme. If you've only ever got one format that's not so hard, but otherwise
you need some good error handling strategies ("whoops, the table's structure
doesn't match my spreadsheet, I'll guess I'll just cut a few columns").
What you're really clamoring for (a uniform way to access databases) has
already been described: it's ANSI SQL. Squeezing all of it into URI form
would be a hell of a job (and you'd end up with some ridiculously big and
unreadable URIs). You could turn the URI into a simple "inject any
system-specific query here" endpoint, but if you do that there's really no
benefit over just exposing a script or application over HTTP to do the same.

Recapping: I could see URIs being used to point to a table or view on an
arbitrary server, but anything more complicated than that goes against the
nature of URIs.

--
J.