Okay, this is the most simple query in the world, and it is somehow failing.
SELECT * FROM kal_auth.dbo.Login WHERE ID = 'Zen' AND PWD = CONVERT(varchar,'0x9248FEFE237DB009')
0x9248FEFE237DB009 is not hex, although it looks like it. but it converts to "Password"
I know this row exists, and its only the password field which is not returning results, this was learned by isolating them and testing.
The PWD field is varchar(16).
I do not understand this.
Use
SELECT CONVERT(VARCHAR,0x9248FEFE237DB009) -- returns ’Hþþ#}°
Not
SELECT CONVERT(varchar,'0x9248FEFE237DB009') -- returns 0x9248FEFE237DB009
By encasing it in quotes it gets treated as a string not as binary data meaning the conversion to varchar doesn't do anything!
I may be missing something here...
The result of CONVERT(varchar,'0x9248FEFE237DB009') is the same '0x9248FEFE237DB009' with 18 chars, isn't it? So how could it be equal to a 16 char password?
Related
I have a database with MANY out-of-date file locations. The difference between the out-of-date file locations and the correct locations is simply the left-side of the address. So, I am attempting to take the left-side off and replace it with the correct string. But, I can't get there because my query is altering the right-side of the address.
This query is made using "vfpoledb."
SELECT RIGHT(LINK,LEN(LINK)-8) ,LEN(LINK)-8,RIGHT(LINK,77),LINK
FROM LINKSTORE
WHERE DOCLBL = "V46145002A"
This query returns the following:
EXP1:
\SHARES\DATA\QMS\QMS DATA\TRACKING FILES\REMOTEENTRIES\V46145 216447
EXP2:
77
EXP3:
\SHARES\DATA\QMS\QMS DATA\TRACKING FILES\REMOTEENTRIES\V46145 216447-002A.PDF
LINK:
\\SERVER\SHARES\DATA\QMS\QMS DATA\TRACKING FILES\REMOTEENTRIES\V46145 216447-002A.PDF
I don't understand why EXP1 and EXP3 are giving different results. EXP3 is what I'm looking for EXP1 to return. If I could get that, I could append the correct left-hand-side and create an update query to fix everything.
Edit:
Even when changing the query to:
SELECT RIGHT(LINK,LEN(LINK)) ,LEN(LINK)-8,RIGHT(LINK,77),LINK
FROM LINKSTORE
WHERE DOCLBL = "V46145002A"
The link still cuts off at the same point, which is odd because expression_3 which still uses Right(), but manually provides the length instead of using Len() does not do this.
Furthermore, it seems that when I run the query to include all results:
SELECT RIGHT(LINK,LEN(LINK)) ,LEN(LINK)-8,RIGHT(LINK,77),LINK
FROM LINKSTORE
WHERE 1=1
All values returned by Exp1 are equal in length even though Exp2 and Link are different in size.
So back to the problem, how can I run a query to replace the left-side with the correct server if I can't separate them out?
OK this is tricky, I did some Foxpro 20 years ago but don't have it to hand.
Your SELECT statement looks OK to me. In the comments under the question Thomas G created this DbFiddle which shows that in a 'normal' dbms, your SELECT statement gives the result you are expecting: https://dbfiddle.uk/?rdbms=sqlserver_2017&fiddle=37047d2b7efb91aaa029fa0fb98eea24
So the problem must be something FoxPro/dBase specific rather than a problem with your SELECT statement.
Reading up I see people say that with FoxPro always use ALLTRIM() when using RIGHT() or LEN() on table fields because the data gets returned padded with spaces. I don't see how that would cause the exact bug you're seeing but you could try this maybe:
SELECT RIGHT(ALLTRIM(LINK),LEN(ALLTRIM(LINK))-8) ,LEN(ALLTRIM(LINK))-8,RIGHT(ALLTRIM(LINK),77),ALLTRIM(LINK)
FROM LINKSTORE
WHERE DOCLBL = "V46145002A"
edit: OK I got a better idea - are there other rows in your result set?
According to this: https://www.tek-tips.com/viewthread.cfm?qid=1706948 ... when you do SELECT (expr) in FoxPro whatever the length of the expr in the first row becomes that max length for that 'field' and so all subsequent rows get truncated to that length. Makes sense in a crazy 1970s sort of way.
So perhaps you have a row of data above the one we are talking about which comes out at 68 chars long and so every subsequent value gets truncated to that length.
The way around it is to pad your expression results with CAST or PADR:
SELECT PADR(RIGHT(ALLTRIM(LINK),LEN(ALLTRIM(LINK))-8),100),LEN(ALLTRIM(LINK))-8,PADR(RIGHT(ALLTRIM(LINK),77),100),LINK
FROM LINKSTORE
WHERE DOCLBL = "V46145002A"
Or same without the ALLTRIM()
SELECT PADR(RIGHT(LINK,LEN(LINK)-8),100),LEN(LINK)-8,PADR(RIGHT(LINK,77),100),LINK
FROM LINKSTORE
WHERE DOCLBL = "V46145002A"
I've written the following SQL query to return all sites having "id" equal to 2.
SELECT * FROM `sites` WHERE id = '2'
And it works well. The problem is that even if I add some characters after "2" like this :
SELECT * FROM `sites` WHERE id = '2etyupp-7852-trG78'
It returns the same results as above.
How to avoid this ? that's to say return none on the second query ?
Thanks
The reason is that you are mixing types:
where id = '2'
------^ number
-----------^ string
What is a SQL engine supposed to do? Well, the standard approach is to convert the string to a number. So this is run as:
where id = 2
What happens when the string is not a number? In most databases, you get a type conversion error. However, MySQL does implicit conversion, converting the leading digits to a number. Hence, your second string just comes 2.
From this, I hope you learn not to mix data types. Compare numbers to numbers. Compare strings to strings.
For some reason I'm unable to use comparisons on GUID columns, it does not return any results.
See below, with the WHERE clause set to the exact value of the 'secguid' column, it does not return any results. What's going on?
SELECT * FROM dbMobileFile
SELECT * FROM dbMobileFile WHERE secguid = '3137459D-EFDE-449E-94A3-89345A8580FA'
SELECT * FROM dbMobileFile WHERE secguid LIKE '3137459D-EFDE-449E-94A3-89345A8580FA'
Using LIKE does not work either.
Try this
SELECT [fileID],
[fileCOde],
[filePassword],
[fileDescription],
[rowguid],
[secguid]
FROM [dbo].[dbMobileFile]
WHERE CAST(secguid as uniqueidentifier) = CAST('3137459D-EFDE-449E-94A3-89345A8580FA' as uniqueidentifier)
Since you mention that the column is stored as NVARCHAR, its possible that the string has leading or trailing whitespaces, which is why it might not be popping up in the query with the WHERE clause.
You can try this :
SELECT [fileID],
[fileCOde],
[filePassword],
[fileDescription],
[rowguid],
[secguid]
FROM [dbo].[dbMobileFile]
WHERE LTRIM(RTRIM(secguid)) = '3137459D-EFDE-449E-94A3-89345A8580FA'
which should show you the result as leading and trailing whitespaces are eliminated in the WHERE clause.
Also, in case you want to make use of the LIKE operator, you can write your query as :
SELECT [fileID],
[fileCOde],
[filePassword],
[fileDescription],
[rowguid],
[secguid]
FROM [dbo].[dbMobileFile]
WHERE secguid LIKE '%3137459D-EFDE-449E-94A3-89345A8580FA%'
Hope this helps!!!
I've had this problem with a corrupt database. Some GUIDs be contained in the WHERE clause, with other GUIDS on the same table would not return results.
Turns out that database had Index issues. Run DBCC to make sure your database isn't corrupt.
The accepted answer works, but it is a bit verbose and probably not the intended way to do this. UniqueIdentifier is qualified by {}, so the following is the easiest;
SELECT * FROM dbMobileFile WHERE secguid = '{3137459D-EFDE-449E-94A3-89345A8580FA}'
See inside the database that guid value stored as 32 hex digits:00000000000000000000000000000000 so if we search by 32 hex digits separated by hyphens: 00000000-0000-0000-0000-000000000000, it's not get any output
Try this:
SELECT * FROM dbMobileFile WHERE secguid = ('3137459D-EFDE-449E-94A3-89345A8580FA')
Use parentheses to enclose GUID string LIKE ('GUID')
I'm trying to retrieve all columns that start with any non alpha characters in SQlite but can't seem to get it working. I've currently got this code, but it returns every row:
SELECT * FROM TestTable WHERE TestNames NOT LIKE '[A-z]%'
Is there a way to retrieve all rows where the first character of TestNames are not part of the alphabet?
Are you going first character only?
select * from TestTable WHERE substr(TestNames,1) NOT LIKE '%[^a-zA-Z]%'
The substr function (can also be called as left() in some SQL languages) will help isolate the first char in the string for you.
edit:
Maybe substr(TestNames,1,1) in sqllite, I don't have a ready instance to test the syntax there on.
Added:
select * from TestTable WHERE Upper(substr(TestNames,1,1)) NOT in ('A','B','C','D','E',....)
Doesn't seem optimal, but functionally will work. Unsure what char commands there are to do a range of letters in SQLlite.
I used 'upper' to make it so you don't need to do lower case letters in the not in statement...kinda hope SQLlite knows what that is.
try
SELECT * FROM TestTable WHERE TestNames NOT LIKE '[^a-zA-Z]%'
SELECT * FROM NC_CRIT_ATTACH WHERE substring(FILENAME,1,1) NOT LIKE '[A-z]%';
SHOULD be a little faster as it is
A) First getting all of the data from the first column only, then scanning it.
B) Still a full-table scan unless you index this column.
I have this query (that runs on Oracle 10g database):
SELECT ge.*, ge.concept AS glossarypivot
FROM s_glossary_entries ge
WHERE (ge.glossaryid = '161' OR ge.sourceglossaryid = '161')
AND (ge.approved != 0 OR ge.userid = 361)
AND concept like 'م%' ORDER BY ge.concept
The query must display all words that begin with the arabic letter "م"
but unfortunately, it returns empty result ..
However, if I run the same query on the same database which runs on MYSQL, it works well and displays the correct result ..
and also, if I run the same query with an english letter (m), like this:
SELECT ge.*, ge.concept AS glossarypivot
FROM s_glossary_entries ge
WHERE (ge.glossaryid = '161' OR ge.sourceglossaryid = '161')
AND (ge.approved != 0 OR ge.userid = 361)
AND concept like 'm%' ORDER BY ge.concept
it displays result correctly and not empty !!
What should I do in order to get this query working the right way on oracle 10 database?
P.S. the oracle database character set is : "AL32UTF8"
thank you so much in advance
Sure that this works in MySQL? I would do this part:
AND concept = 'م'
like this:
AND concept LIKE 'م%'
or because it's arabic and the first char is the right one's like this:
AND concept LIKE '%م'
But i have no idea if Oracle even have LIKE, i never worked with Oracle.
if I put a UTF8 character : " ظ… " instead of the arabic character "م" it will work on oracle ...
The obvious question is, do you have matching data.
You can use SELECT DUMP(concept), DUMP('م') FROM ... to see the bytes that actually form the value. My database gives me 217/133. I believe there are some characters which can have different bytes in UTF-8 but the same physical appearance, though I couldn't say whether this is one of them.
Also, consult the Globalization guide.
i thjink its a mismatch in your oracle client codepage. it should be defined in the same character set as the database, otherwise there will be some character conversion.