I am working on data compression and for some reason i need only 8 bits.
I am converting number by decbin() and then inserting it in the mysql, the mysql column data type BIT width is 8 bit. I used mysql_query("INSERT INTO n (reading) VALUES (b'".$value."')") and tried this one toomysql_query("INSERT INTO n (reading) VALUES (".$value.")"). Before inserting the value is fine but after insertion its not the same value, it changes the value for example before insertion it echo the value 116 then I echo its binary value 1110100 and it insert the value in mysql column is 00110000.
function delta($reading){
global $flag;
$delta = $flag - $reading;
saveDelta(decbin($delta));
}
here is the other function where it saves the value
function saveDelta($dif) {
mysql_query("INSERT INTO n (reading) VALUES (".$dif.")");
}
The syntax "INSERT INTO n (reading) VALUES (b'".$value."')" should work provided that $value is properly encoded as a string of '0' and '1'.
EDIT: I noticed you didn't provide any "sequence number" while inserting your data. But, please remember that without using a proper ORDER BY clause, you cannot retrieve your bytes the order they where entered at first. Maybe you think you read "116" but MySQL return an other row from the table?
Here are some usage examples, First using the BIT type:
CREATE TABLE b (value BIT(8));
INSERT INTO b VALUES (0),(1), (255);
INSERT INTO b VALUES (b'00000000'),(b'00000001'), (b'11111111');
Please note that when retrieving BIT columns you will obtain signed result (i.e.: storing 255 will read -1).
You could retrieve your data either as signed 10-base integers or binary form (with optional padding):
SELECT value FROM b;
SELECT BIN(value) FROM b;
SELECT LPAD(BIN(value), 8, '0') FROM b;
As of myself, I would prefer the TINYINT UNSIGNED. This is an 8 bit type which support the same syntax for values (either <10-base digit> or b'xxxxxxxx') -- but will accept the UNSIGNED specifier:
CREATE TABLE t (value TINYINT UNSIGNED);
INSERT INTO t VALUES (0),(1),(255);
INSERT INTO t VALUES (b'00000000'),(b'00000001'), (b'11111111');
You could retrieve your data either as unsigned 10-base integers or binary form (with optional padding):
SELECT value FROM t;
SELECT BIN(value) FROM t;
SELECT LPAD(BIN(value), 8, '0') FROM t;
See http://sqlfiddle.com/#!2/4ff44/6 to experiment with both of them.
Related
I am trying to save a string in binary to save space in my MySQL DB. However, I am unable to retrieve the binary data correctly, so what am I doing wrong?
I have a database like:
CREATE TABLE `Test` (
ID INT NOT,
Value BLOB
);
I insert the data with statements like:
INSERT INTO `Test` (ID, Value) VALUES(1, b'10000001');
However, I can't retrieve the binary string when I select the value from the inserted row with the underneath query:
SELECT * FROM `Test`; //NOT WORKING. Returns Value=0
SELECT ID, BIN(Value) FROM `Test`; //NOT WORKING. Returns Value=0
What should I use? I have already tried using BIN(Value) in my query as shown above, but without any success. Thanks in advance.
Starting with a literal string of ones and zeroes is incredibly odd, but:
$ones_and_zeroes = '10000001';
// If you have a literal string of ones and zeroes that you need to convert
// to an actual number there's base_convert()
$hex_string = base_convert($ones_and_zeroes, 2, 16);
// $hex_string is now "81"
// you can convert this to an *actual* binary string with hex2bin()
$bin = hex2bin($hex_string);
// $bin now contains the byte 0x81
// now if you want to do it right:
$dbh = new PDO( ... );
$stmt = $dbh->prepare('INSERT INTO `Test` (ID, Value) VALUES(1, :bin)');
$stmt->execute(['bin'=>$bin]);
// or whatever the gross mysqli equivalent is.
I'm not going to show you how to do it wrong in PHP, but of you wanted to hand-write this query it would be:
INSERT INTO `Test` (ID, Value) VALUES(1, 0x81);
Hex-encoded data prefixed with '0x' being the only safe way [that I am aware of] to embed binary data in a text query, though it is EMINENTLY preferable to use prepared statements whenever possible as hex-encoding data like this doubles the length.
The best advice is to check if the insert query ran successfully i.e. with expected data inserted into DB using any MySQL admin tool.
Only then can you isolate whether the problem is with the retrieval or the insets itself
I actually get very mad about PHP and SQLite3 and the way some of my strings behave there.
I try to save opening hours but in strings instead of numeric to prevent problem with leading zeros (and still have it now haha... -.-).
Hours and minutes have their own column but when I insert '0x' the zero is gone and whatever x is, is left in the database. :/
Im sure im just missing some little damn part somewhere...
I already checked the INSERT-statement but found nothing at all.
Example for an insert string:
INSERT INTO opening INSERT INTO opening (start_day, end_day, start_hour, start_minute, end_hour, end_minute) VALUES('Montag', 'Freitag', '00', '00', '01', '00')
But the output is:
11|Montag|Freitag|0|0|1|0
Part of the Code:
class Database_Opening_Hours extends SQLite3{
function __construct() {
if(!file_exists("../../data/opening_hours/opening_hours.sqlite")){
$this->open("../../data/opening_hours/opening_hours.sqlite");
$this->exec('CREATE TABLE opening (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, start_day STRING, end_day STRING, start_hour STRING, start_minute STRING, end_hour STRING, end_minute STRING)');
}
else{
$this->open("../../data/opening_hours/opening_hours.sqlite");
}
}
}
$db = new Database_Opening_Hours();
$insert = "INSERT INTO opening (start_day, end_day, start_hour, start_minute, end_hour, end_minute) VALUES('".htmlspecialchars($_GET["start_day"])."','".htmlspecialchars($_GET["end_day"])."','".$start_hour."','".$start_minute."','".$end_hour."','".$end_minute."')";
if($db->exec($insert)){
$db->close();
unset($db);
echo "Insert erfolgreich";
}else{
$db->close();
unset($db);
echo "Nicht wirklich...";
}
Fairly sure that the type of your columns is set to an integer (or any other number type) instead of TEXT.
Make sure to double check the column data type and actually dump the table for us to check if it's really set to TEXT.
This is caused by SQLite using dynamic typing. From the FAQ:
This is a feature, not a bug. SQLite uses dynamic typing. It does not enforce data type constraints. Data of any type can (usually) be inserted into any column. You can put arbitrary length strings into integer columns, floating point numbers in boolean columns, or dates in character columns. The datatype you assign to a column in the CREATE TABLE command does not restrict what data can be put into that column. Every column is able to hold an arbitrary length string.
And from the linked page (emphasis mine):
In order to maximize compatibility between SQLite and other database engines, SQLite supports the concept of "type affinity" on columns. The type affinity of a column is the recommended type for data stored in that column. The important idea here is that the type is recommended, not required. Any column can still store any type of data. It is just that some columns, given the choice, will prefer to use one storage class over another. The preferred storage class for a column is called its "affinity".
So SQLite is dynamically casting your values to integer.
I would suggest combining start_hour and start_minute into start_time (the same for the end_ fields) and storing the value in the format 00:00.
SQLite will store this 'as-is' but is smart enough to recognise a time value and allow you to perform date/time operations:
select time(start_time, '+1 hour') from opening
I had this problem with C/C++ because I did not quote the strings:
insert into test values('aa', 'bb');
use varchar instead of string, I had the same problem then I used varchar(length) and it worked fine
Hopefully I'm going about this the right way, if not I'm more than open to learning how this could be done better.
I need to pass a comma separated list of integers (always positive integers, no decimals) to a stored procedure. The stored procedure would then use the integers in an IN operator of the WHERE clause:
WHERE [PrimaryKey] IN (1,2,4,6,212);
The front-end is PHP and connection is made via ODBC, I've tried wrapping the parameter in single quotes and filtering them out in the stored procedure before the list gets to the query but that doesn't seem to work.
The error I'm getting is:
Conversion failed when converting the varchar value '1,2,4,6,212' to data type int.
I've never done this before and research so far has yielded no positive results.
Firstly, let's use a SQL Function to perform the split of the delimited data:
CREATE FUNCTION dbo.Split
(
#RowData nvarchar(2000),
#SplitOn nvarchar(5)
)
RETURNS #RtnValue table
(
Id int identity(1,1),
Data nvarchar(100)
)
AS
BEGIN
Declare #Cnt int
Set #Cnt = 1
While (Charindex(#SplitOn,#RowData)>0)
Begin
Insert Into #RtnValue (data)
Select
Data = ltrim(rtrim(Substring(#RowData,1,Charindex(#SplitOn,#RowData)-1)))
Set #RowData = Substring(#RowData,Charindex(#SplitOn,#RowData)+1,len(#RowData))
Set #Cnt = #Cnt + 1
End
Insert Into #RtnValue (data)
Select Data = ltrim(rtrim(#RowData))
Return
END
To use this, you would simply pass the function the delimited string as well as the delimiter, like this:
SELECT
*
FROM
TableName
WHERE
ColumnName IN (SELECT Data FROM dbo.Split(#DelimitedData, ','))
If you still have issues, due to the datatype, try:
SELECT
*
FROM
TableName
WHERE
ColumnName IN (SELECT CONVERT(int,Data) FROM dbo.Split(#DelimitedData, ','))
You can pass a comma separate list of values. However, you cannot use them as you like in an in statement. You can do something like this instead:
where ','+#List+',' like '%,'+PrimaryKey+',%'
That is, you like to see if the value is present. I'm using SQL Server syntax for concatenation because the question is tagged Microsoft.
I am trying to match a md5 has (generated through php) to its original value in a SQLExpress database.
I am using the following function in my SQL query
master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', 'ID'), 1, 0)
Where 'ID' is the field in the database.
However they both seem to return different values for the md5 hash. I have been using '12290' as a static value to test this.
php md5() returns: 0bd81786a8ec6ae9b22cbb3cb4d88179
The following SQL Statement returns the same output:
DECLARE #password VARCHAR(255)
SET #password = master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', '12290'), 1, 0)
SELECT #password
Yet when I run the following statement from the table:
SELECT ID, master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', CONVERT(NVARCHAR(255), ID)), 1, 0) AS temp
FROM Clients
ORDER BY ID ASC
The 'temp' value matching to the 'ID' value of 12290 returns: 1867dce5f1ee1ddb46ff0ccd1fc58e03
Any help on the matter would be much appreciated!
Thanks
Python helped me to help you.
>>> from hashlib import md5
>>> md5('1\x002\x002\x009\x000\x00').digest().encode('hex')
'1867dce5f1ee1ddb46ff0ccd1fc58e03'
NVARCHAR is Unicode type and it seems from the above experiment that '12990' is stored as UTF-16LE in your database: '1\02\09\09\00\0'.
Assuming that the data encoding in the PHP is UTF-8 data and you don't want to change the existing data in the database, this is how you can fix your PHP script:
<?php
$password = '12290';
$hash = md5(mb_convert_encoding($password, 'UTF-16LE', 'UTF-8')) . "\n";
echo $hash;
?>
Output:
susam#swift:~$ php utf16le-hash.php
1867dce5f1ee1ddb46ff0ccd1fc58e03
In case the data in PHP is in some other encoding such as ASCII, ISO-8859-1, etc. you can change the third argument to mb_convert_encoding accordingly. The list of all supported encodings is available at: http://www.php.net/manual/en/mbstring.supported-encodings.php
Also, see http://www.php.net/manual/en/function.mb-convert-encoding.php
I don't have SQL server to test this on, but the CONVERT command might be creating the NVARCHAR with 240-odd trailing blanks (as you have specified NVARCHAR(255))
Try setting the NVARCHAR to the length of the ID to test:
ARE #password VARCHAR(255)
SET #password = master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', CONVERT(NVARCHAR(5), '12290')), 1, 0)
SELECT #password
Try with different lengths in the CONVERT - is there any difference?
One of two things is most likely the problem:
Either the ID column in that row has a value not exactly equal to '12290' (e.g. extra whitespace)
Or the CONVERT function produces such a value
In any case, a standard debugging approach would be to use an SQL query to SELECT the string lengths of that ID field and the return value of CONVERT; if either is not equal to 5, you found the error.
Alternatively you can perform a dump of the table in question including data, and look at the generated INSERT statement to see what the database says the value in that column is.
I'm using SQLite 3 with PHP.
The SQLite table consists of 2 INTEGER and one FLOAT column. When saving data into this table using PHP floats are not saved correctly (default value is stored instead). The two integer columns are saved. Any ideas what could be wrong? Thank you.
Simplified code that actually works correctly:
$conn = new SQLite3('dbFileName');
$conn->query("CREATE TABLE data (
id INTEGER NOT NULL DEFAULT 0 ,
ts INTEGER NOT NULL DEFAULT 0 ,
value FLOAT NOT NULL DEFAULT 0
);"
);
$conn->query("REPLACE INTO data(id,ts,value) VALUES ('1','1234567890','12.1')");
-> 1|1234567890|0
This is just a suggestion, seeing as I have never used SQLite, but are you sure the numbers should be quoted? That seems somewhat odd to me.
Try:
$conn->query("REPLACE INTO data(id,ts,value) VALUES (1, 1234567890, 12.1)");
Sqlite data types are typeless, so your queries have to work:
all the following queries works for me
REPLACE INTO data(id,ts,value) VALUES ('1','1234567890','12.1');
REPLACE INTO data(id,ts,value) VALUES ('1','1234567890','12,123')
REPLACE INTO data(id,ts,value) VALUES ('1','1234567890','abc');
Check your PHP variable, you might have a bug and you pass a null variable.