I am executing a simple select query in mysql. When I view the values using phpMyAdmin, everything looks normal. But once I execute a select query in terminal.. Irregular characters like these show.
��S8"�����g��n��Q�5��S:���p/��F;X�.�g����W�=��r+:��J�3W
\��S�R��CΤS�4�9�#�5���lˠ��bc�Q�}Q��(8>Vm���0�RU6L�FO#�W����W�SR>~�9$�-Q[XȲ�z�L�T�j �~���#˔{���ZQUX�ǑZ:L&[�־[-�>z)5�A�ּd 9��H����^��w��xq&���kK��ʺs��R*-�3�Z����� ��#i ����;��C
�־������
The phpMyAdmin interface can handle unicode - your terminal cannot
Related
I'm trying to use mysql workbench as a query editor for my project. My output in the results viewer looks like this:
Even if I set varbinary/binary characters to show up as non-binary I still get this output. And it is for all fields whether they be text, int, date, etc.
Can anyone help?
You must choose "Query" - "Execute (All or Selection) to text" in the up menu
I'm using a GUI MySQL manager called Sequel Pro on my Mac.
Historically, when I'd right-click a row and click "Copy as SQL Insert", it would copy a standard-looking MySQL insert statement containing the row contents in plain text.
I noticed the other day when doing this, the output now looks like this:
INSERT INTO `config` (`key`, `value`)
VALUES
(X'68656C6C6F5F737461636B5F6F766572666C6F77', X'5468616E6B7320666F7220616E73776572696E67206D79207175657374696F6E');
What is with the random letter/number strings beginning with X? Starting a string with an X doesn't look like standard SQL syntax. Somehow though, when I run the SQL command it enters a valid new record with the data I would expect into the table.
What feature is this, what benefit does it serve, and why did it suddenly change since last week?
It's a SQL standard to escape binary literals in the format:
x'hexstring'
Like the following:
x'68656C6C6F5F737461636B5F6F766572666C6F77'
According to a comment on the documentation for the BINARY and VARBINARY Types, MySQL also supports the ODBC standard:
0x68656C6C6F5F737461636B5F6F766572666C6F77
(Sorry for the longish question, I'll try to be concise.)
I'm running SQL Server Profiler and I'm chasing down some performance issues. I'm relatively new to what the profiler does and I've exported the traces into a table so I can run queries against the data.
One thing I've been running up against is some seemingly odd behavior doing select queries against the TextData field of the table generated by the trace export. It may have to do with the field's data type (ntext, null). I'm selecting for particular values, but getting unexpected results. For example, if I do this:
select * from [TraceAnalyzer].dbo.TraceTable
and I'm interested in values like this:
exec [Sproc_of_interest] #parm1=992
I'd do a query like this:
select * from [TraceAnalyzer].dbo.TraceTable
where TextData like '%exec [Sproc_of_interest] #parm1=%'
but the return result is empty.
Also, if I do a query like:
select * from [TraceAnalyzer].dbo.TraceTable
where TextData like '%exec [Sproc_of_interest]%'
I get unexpected TextData values like exec sp_reset_connection
Would the square brackets in the criteria be messing things up? I've tried omitting them, but that just excludes everything. I'm not aware of escape characters in SQL select queries, but when I copy/paste the value from one of the offending records, the pasted value does not appear to contain anything that would meet the original query's criteria.
Any insights would be greatly appreciated. Thanks.
[Sproc_of_interest] in the pattern syntax is interpreted as matching one character that is in the set S,p,r,o,c,_,o,f,_,i,n,t,e,r,e,s,t.
Three possible ways of solving this are below.
1) Escape [ with square brackets
LIKE '%exec [[]Sproc_of_interest] #parm1=%'
2) Use an escape character
LIKE 'exec \[Sproc_of_interest] #parm1=' ESCAPE '\'
3) Use CHARINDEX instead of escaping anything
WHERE CHARINDEX('exec [Sproc_of_interest] #parm1=' , TextData) > 0
I'm executing a SELECT query on a table in MySQL using the command-line interface (not a GUI client):
SELECT * FROM blog_entry;
One of blog_entry's fields is of type 'longtext' and is such a long piece of text that when the result is displayed in my terminal the display of rows takes more than one line. This causes an ugly mess of a display, where columns aren't easily visible. What technique can I use in my SELECT query that would limit the number of characters displayed for each field so that the printed row results don't overflow to new lines?
Use MySQL's SUBSTRING function, as described in the documentation. Like:
SELECT SUBSTRING(`text`, 1, 100) FROM blog_entry;
To select first 100 chars.
You can use the LEFT() function to get only the first characters:
SELECT LEFT(LongField, 20) AS LongField_First20chars
FROM ...
The best way to clean up the readability of the results from a query in your terminal window is to use the mysql pager, not modifying your query as that can be too cumbersome.
Set the pager:
mysql> pager less -S
Do your query:
mysql> SELECT * FROM ...
This will put your results in a more readable format. You can use your arrow keys to page up and down and left and right to see the full table. Just press Q to get out of pager mode for that query, and then just run
mysql> pager more
to return to the normal output river if you want.
Select Cast(theLongTextField As VarChar(100)) From blogEntry
I don't have phpMyAdmin installed in my web site.
Sometimes I was doing some select SQL command at the backend,
but when I typed in this command to show all records from table Users:
select * from Users;
The records were printed as ???? | ??? ??? ??? |.
I don't want to make any permanent changes to the charset in the database,
so, how is it possible to temporarily displayed a few records as utf8 when needed?
> CONVERT()
provides a way to convert data between different character sets
example:
SELECT CONVERT(newvalue USING utf8);
Just put 'N' before your queries like
select * from User where id = N'یونیکد'
take a look at the mysql CONVERT-statement, i think thats what you are looking for. if i remember right, the syntax is like this:
SELECT CONVERT(username USING utf8) FROM users...;