Reading from SQL Server

[Monig]

I am not sure i'm posting my question in the right place but...

i am trying to read data from SQL server data base using ODBC (reading the data into JMP - a statistical analysis software).

at first i could not read the Unique ID at all, getting blanks.
i tried casting the UID as CHAR and got some strings -

my question is:

is the string i get after i convert the UID to CHAR still unique ?
can I use this string as a key to combine data from different tables ?

[azimmer]

I am not sure i'm posting my question in the right place but...

i am trying to read data from SQL server data base using ODBC (reading the data into JMP - a statistical analysis software).

at first i could not read the Unique ID at all, getting blanks.
i tried casting the UID as CHAR and got some strings -

my question is:

is the string i get after i convert the UID to CHAR still unique ?
can I use this string as a key to combine data from different tables ?

The answer -- to the best of my knowledge -- is: yes and yes. I've found it, however, good practice to create views of the data to be access to this end in the SQL Server and query the views only. (This is esp. true for MS Query where joins are awkward.)

[ck9663]

I am not sure i'm posting my question in the right place but...

i am trying to read data from SQL server data base using ODBC (reading the data into JMP - a statistical analysis software).

at first i could not read the Unique ID at all, getting blanks.
i tried casting the UID as CHAR and got some strings -

my question is:

is the string i get after i convert the UID to CHAR still unique ?
can I use this string as a key to combine data from different tables ?

if your UID in the table is unique, then it should also be unique. if it's char to integer, you might have a problem since '010' is equal to '10', converted.

[Monig]

if your UID in the table is unique, then it should also be unique. if it's char to integer, you might have a problem since '010' is equal to '10', converted.

thanks,
I will go ahead and use it. hope it works (its a pretty complicated dastabase..)

[Monig]

The answer -- to the best of my knowledge -- is: yes and yes. I've found it, however, good practice to create views of the data to be access to this end in the SQL Server and query the views only. (This is esp. true for MS Query where joins are awkward.)

thanks,
what are the risks if i cannot use views? (this is a customers's data base and they dont want to add any views in fear of "choking" thed server - it is quite a big and complcated data base).

[azimmer]

thanks,
what are the risks if i cannot use views? (this is a customers's data base and they dont want to add any views in fear of "choking" thed server - it is quite a big and complcated data base).

Well it's basically not about risks, it's more about convenience. In MS Query only one outer join is allowed per query which is not always enough. Plus if the data needs to be transformed (with CASEs, CONVERTs, etc.) the resulting query will be hard to read, much easier in an SQL environment (e.g. Query Analyzer). If that's not enough, if you use the same (or similar) set of data for more than one client side query you have to maintain server side views only once as opposed to each client side query.

I accept that the customer is unwilling to add views to the DB but their quoted reasons are false: a view is not any more computation-intensive than a query (because that's what it is)... Plus: if you don't need real-time data, you can set up a table for your query that gets updated every so often and thus reduces load, and they can limit your access to that one table only.