January 6, 2011 at 1:49 pm
We have the "update" table with the clients' "client_fk" (format 'ntext') number that relates to the "client_pk" (format 'uniqueidentifier") number residing in the "client_demo" table. When I do a query and try join the tables on these two, I am told that I cannot use the ntext field in a comparison with '=' and it is not compatible with the uniqueidentifier. The actual raw string in the fields are the same. Is there any way around this ?
Thank you !
January 6, 2011 at 1:56 pm
Can you change the data type of the ntext column? If it's only storing GUID values, why not use the uniqueidentifier data type?
January 6, 2011 at 2:34 pm
You're right...however, I should have explained more...it's not my database. I might be able to download it to my machine but its huge, etc. I'm relatively new to SQL (I mostly use MUMPS). I didn't know if there was any type of on-the-fly conversion type function that I could use in the join. I guess worst case I ceate a temp table to play with.
January 6, 2011 at 2:55 pm
Try using CAST( nTextField AS nVARCHAR(MAX)) = uniqueIDField.
It'll run like a three legged dog, but it should run.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
January 6, 2011 at 2:58 pm
A dirty work-around is to use the CONVERT function to convert the ntext column to a uniqueidentifier in the JOIN expression. If it's not your database and you can't change the design, then that is the only option I can think of.
Keep in mind that if any value in the ntext column cannot be converted to a uniqueidentifier, then you'll get an error.
If that happens your only option is to convert both columns (the ntext and uniqueidentifier) to varchar/nvarchar.
But be careful with this approach. SQL Server will have to build a temporary hash table (in tempdb) for the values produced by the CONVERT function, and this will use extra memory, disk I/O and CPU.
January 6, 2011 at 3:04 pm
Thank you everyone !!!!
I'll try it...we have 28 change logs each in their own database that I want to make a lookup file to facilitate a lookup without having to go into the actual system (VB) and go client by client. I will be running this once per change log then from the main database, I can query as need be. If it takes all night to run (while all the users are asleep), so be it.
Again, Thank you !!
April 16, 2013 at 12:21 pm
have found a crude yet effective simple remedy to the implicit guid datatype conversion issue.
I've been working with the problem where a GUID may be a NULL value and causes the error of not being able to convert value of string/char to uniqueidentifier .. from everything I've read so far it basically comes down to order of prescedence .. and that the unique identifier data type superceedes any functions you try to impose to do the val1 = val2 comparision with any form of Cast, Convert or IsNull work around.
What I eventually came up with, and this is going to sound very kindergarden coder so I appologize to all of those of you that are infinately more skilled in this area, just use a replace function call on the two values to remove the "-" in the guid and trim any spaces off and the error will not come up again
I think by saying (replace(rtrim(ltrim(val1,'-','') = (replace(rtrim(ltrim(val2,'-','') and replace(rtirm(ltrim(val1,'-','') and (replace(rtrim(ltrim(isnull(val1,''))),'-','') <> ''
you circumvent the implicit guid/unique identifier conversion and it will run for you
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply