I want to join two tables on a UUID. table A's UUID is represented as varchar(32). table B's UUID is represented as binary(16).
what's the best way to join a varchar to a binary column?
I've tried using some sybase functions for this, but I'm getting different results and unsure of why:
select hextobigint('0x000036ca4c4c11d88b8dcd1344cdb512')
3948051912944290701
select convert(bigint,0x000036ca4c4c11d88b8dcd1344cdb512)
-2877434794219274240
what am I missing about convert and hextobigint? I must be misundstanding at least one of these functions. thanks for your help!
got it eventually with the help of some colleagues:
select strtobin(convert(char(32), '000036ca4c4c11d88b8dcd1344cdb512'))
The problem is on the select convert(bigint,0x000036ca4c4c11d88b8dcd1344cdb512).
If you remove the first zeros it'll give you the same result:
select hextobigint('0x000036ca4c4c11d88b8dcd1344cdb512')
and
select convert(bigint,0x36ca4c4c11d88b8dcd1344cdb512)
Related
I want rows but in WHERE I have different values. How can I get these rows? Let's say I want to check names of people with different cnic values?
select name from table where cnic='123','234','134';
It gives me an error. How can I do this?
use mysql In operator for checkinng multiple values.
select name from table `where cnic IN ('123','234','134');
Please use the In operator for this
select name from table where cnic in ('123','234','134')
I'm trying to join two fact tables in a Netezza DB on a common acct_nbr field. In table a, it's BIGINT, and in table b it's coded as VARCHAR. (I have no control over the table design, and I suspect it's set up as VARCHAR because it's populated by web input, and needs to be able to tolerate typos.) I'd like to disregard the alpha characters for the join - I'm willing to rule out all fields in table b that contain non-numeric characters. (The field also contains -,?,!, etc.)
I've tried the following:
A basic join. Throws Bad int8 representation for '9999R99999', I assume based on the first non-convertible VARCHAR entry it comes across.
Using cast/convert on both fields (to BIGINT for b.acct_nbr, to VARCHAR for a.acct_nbr) which I may have implemented incorrectly. Various errors, no results.
Using "select ... from table_a a join table_b b on (a.acct_nbr=b.acct_nbr and b.acct_nbr not like '%[^0-9]%')". I don't seem to be able to make this work, and I haven't found a good explanation for how the '%[]%' syntax works. I know what % does, but I've a poor understanding of how to use the carat and the brackets.
I'm sure this is a simple problem, but I'm banging my head against the wall. Any help is much appreciated!
You can complete the join a few different ways.
select ...
from table_a a join
table_b b on (a.acct_nbr=b.acct_nbr
and translate(b.acct_nbr,'1234567890','') in ('','.','-','-.')
Or if you have the sql functions toolkit installed you could do this.
select ...
from table_a a join
table_b b on
(a.acct_nbr=sql_functions..regexp_extract(b.acct_nbr,'^[0-9]{1,18}')
I'm comparing account numbers in two different databases to make sure the account exists in both. The account field in one database is nvarchar and the other it's varchar. I do a cast to cast them both to varchar(12) and join them to see where there isn't a match. If there is an account number with less than 12 characters then it thinks it's not a match. I'm assuming the extra characters in each field are causing the issue?
table1 - accountnumber(nvarchar(255))
table2 - accountnumber(varchar(20))
select * from
table1
left outer join table2 on table2.accountnumber = table1.accountnumber
In this one example, both tables have an account with the number 12345678, but the join isn't working. I'm not sure if it's data type mismatch or white space or something else.
--Added--
I should add that the data in table2 actually originates from an Oracle database where it's stored as a varchar2(12 byte). I import it into a SQL Server database where it's stored as a varchar(20). I'm not sure if this makes a difference.
Not sure where you are having a problem. This query should return matching account numbers (no need to CAST):
SELECT *
FROM YourTable
JOIN YourOtherTable ON YourTable.AccountNumber = YourOtherTable.AccountNumber
If your data has spaces, you can TRIM your data depending on your RDBMS -- LTRIM and RTRIM for SQL Server.
SELECT *
FROM YourTable
JOIN YourOtherTable ON RTRIM(LTRIM(YourTable.AccountNumber)) = RTRIM(LTRIM(YourOtherTable.AccountNumber))
Here is the SQL Fiddle.
Good luck.
Your query works fine. This is perhaps a character encoding issue. Try using collate. See this previous SO answer which might help.
I ran into absolutely same case, I had even two sibling queries (one created as a copy of another), which both had this problem. Collation and types were no issue here.
Finally after a LOT of testing, one of the queries started to work without aparent changes, just re-written. When I retyped the IN part of the second query, it started to work too.
So there was a problem with a hidden character accidentally typed somewhere in the query.
I have a query in MS Access which creates a table from two subqueries. For two of the columns being created, I'm dividing one column from the first subquery into a column from the second subquery.
The datatype of the first column is a double; the datatype of the second column is decimal, with scale of 2, but I want the second column to be a double as well.
Is there a way to force the datatype when creating a table through a standard make-table Access query?
One way to do it is to explicitly create the table before putting anything into it.
Your current statement is probably like this:
SELECT Persons.LastName,Orders.OrderNo
INTO Persons_Order_Backup
FROM Persons
INNER JOIN Orders
ON Persons.P_Id=Orders.P_Id
WHERE FirstName = 'Alistair'
But you can also do this:
----Create NewTable
CREATE TABLE NewTable(FirstName VARCHAR(100), LastName VARCHAR(100), Total DOUBLE)
----INSERT INTO NewTableusing SELECT
INSERT INTO NewTable(FirstName, LastName, Total)
SELECT FirstName, LastName,
FROM Person p
INNER JOIN Orders o
ON p.P_Id = o.P_Id
WHERE p.FirstName = 'Alistair'
This way you have total control over the column types. You can always drop the table later if you need to recreate it.
You can use the cast to FLOAT function CDBL() but, somewhat bizarrely, the Access Database Engine cannot handle the NULL value, so you must handle this yourself e.g.
SELECT first_column,
IIF(second_column IS NULL, NULL, CDBL(second_column))
AS second_column_as_float
INTO Table666
FROM MyTest;
...but you're going to need to ALTER TABLE to add your keys, constraints, etc. Better to simply CREATE TABLE first then use INSERT INTO..SELECT to populate it.
You can use CDbl around the columns.
An easy way to do this is to create an empty table with the correct field types and then to an Append-To query and Access will automatically convert the data to the destination field.
I had a similar situation, but I had a make-table query creating a field with NUMERIC datatype that I wanted to be short text.
What I did (and I got the idea from Stack) is to create the table with the field in question as Short Text, and at the same time build a delete query to scrub the records. I think it's funny that a DELETE query in access doesn't delete the table, just the records in it - I guess you have to use a DROP TABLE function for that, to purge a table...
Then, I converted my make-table query to an APPEND query, which I'd never done before... and I just added the running of the DELETE query to my process.
Thank you, Stack Overflow !
Steve
I add a '& ""' to the field I want to make sure are stored as text, and a ' *1 ' (as in multiplying the amount by 1) to the fields I want to store as numeric.
Seems to do the trick.
To get an Access query to create a table with three numeric output fields from input numeric fields, (it kept wanting to make the output fields text fields), had to combine several of the above suggestions. Pre-establish an empty output table with pre-defined output fields as integer, double and double. In the append query itself, multiply the numeric fields by one. It worked. Finally.
I'm working with 2 related tables in a Microsoft SQL Server 2008 environment which are connected via a GUID. In one table, the field has the type varchar(50), the other one is properly types as uniqueidentifier. This is obviously bad but I can't change this now because it's given by a legacy piece of software.
The conversion SQL Server needs to perform at each inner join makes queries running terribly slow, since I can't use indices at all. I tried adding a Computed Column, which is persisted, to get the ID stored as a uniqueidentifer. This way I could add an index to get it running much faster probably. I failed.
Does anybody know if I can store an explicitly converted value in a computer column. If I can, what's the formula to use here?
Cheers,
Matthias
This worked for me:
CREATE TABLE t_uuid (charid VARCHAR(50) NOT NULL, uuid AS CAST(charid AS UNIQUEIDENTIFIER))
CREATE INDEX IX_uuid_uuid ON t_uuid (uuid)
INSERT
INTO t_uuid (charid)
VALUES (NEWID())
SELECT *
FROM t_uuid
CONVERT(uniqueidentifier, your_varchar_here)
Depending on how often you need to make the conversion for joining, I'd use a CTE to convert the data type(s). It is constructed faster than an inline view (next best temporary option). In either case, you'd expose value as the correct data type in a result column from the CTE/inline view so you can JOIN on to it. CTE Example:
WITH example AS (
SELECT t.guid
CONVERT(UniqueIdentifier, t.guid) 'cguid'
FROM TABLE t)
SELECT t.*
FROM TABLE t
JOIN example e ON e.cguid = t.guid
Inline view example:
SELECT t.*
FROM TABLE t
JOIN (SELECT t.guid
CONVERT(UniqueIdentifier, t.guid) 'cguid'
FROM TABLE t) e ON e.cguid = t.guid
It's not going to get around that the index for guid (assuming one does) won't be used, but it's also not a good habit to be performing data type conversion in the WHERE clause.