Thanks in advance for any help!
I have several different mysql columns (which are imported from a product feed) that I'm trying to convert into one to work with a custom plugin for Opencart.
The format of the MYSQL entry for the plugin is as follows...
a:11:{i:13;s:3:"964";i:14;s:9:"Automatic";i:15;s:3:"FWD";i:16;s:15:"Gas I6 4.2L/256";i:17;s:5:"Black";i:18;s:4:"Gray";i:19;s:12:"Some City, ST";i:20;s:2:"15";i:21;s:2:"21";i:22;s:6:"128365";i:23;s:17:"2XXXXG3XXXXH5XXXX";}
As you can see, the "s:X" represents the character count for each entry. I have 11 different columns with the info I'm trying to convert to this format, but without an accurate character count the plugin throws an error. So i'm trying to use a combo of sql/php to get an accurate character count that I can use to make this work. I have a handle on everything else.
SO!
My question is...how do I assign the character count to a variable? I did some googling and I found this...
SELECT CHAR_LENGTH('TABLENAME');
I realize there's more to it, just wondering how to set it as a variable.
AND
Not terribly important, but does anyone recognize the format? I've never seen this before!
Serialized PHP Array
Not sure if this will help anyone in the future since this is pretty specific, but based on the info I got from jraede (thanks alot!). I was able to load all 11 columns into a PHP array and serialize, then upload to DB. WAY easier than trying to create 11 variables for character count!
Related
I know this has been asked a thousand times but what I am currently doing seems to be the general answer I see online and it is still not working correctly.
I am populating an excel document from a SQL query in which one of the columns is a ISBN10 of which can start with a 0 (but not every time) The excel rows are populated with a for each loop of which I have done in the past with no issues I've then added :
$objPHPExcel->getActiveSheet()->setCellValue('B'.$c,$row['isbn10']);
$objPHPExcel->getActiveSheet()->getStyle('B'.$c)->getNumberFormat()
->setFormatCode('0000000000');
To state that this field will be 10 digits (at least that is my current understanding that the setFormatCode will do, when the xls file is downloaded however the ISBN column still trims off all leading zeros, I'm a bit stumped with what to do as a lot of answers I've seen say this is the method you need to stop this happening?
Does anyone here have any ideas of what could possibly solve this?
I have a database with many columns all with year names. Inside of them on every row are numbers with a type of integer. I want them to all have thousand seperators (A dollar sign would be nice but I can add that in easy with php).
-What I have now is the following:
SELECT *, format(`2015`, 0) AS `15`, FROM `FullList`
and that gives me the seperators like 1,000,000. The problem is I would have to do that for every column that seems wrong.
in my php I use this as simply
<div class=\"example\">$".$row[`15`]."</div>
Giving me $1,000,000
I'm hoping to find a good way of doing this in SQL or maybe even PHP so that I don't need to use format on every column.
Databases should not contain formatting because you are storing information in a standard form which can be read by any application regardless of language. I suppose the column is currently of data-type float(11,2) or something similar, which is correct and recommended.
Though it may seem tedious to add a dollar sign in front of every value, displaying a value should be the job of the templating language (in this case PHP) and not the database.
You might want to use PHP's money_format() instead:
http://php.net/money_format
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Are there any reserved words in SQLite?
I have a big database (veekun's pokedex for those who know of it) and one table has a column named "order". It's for sorting purposes, and I'm trying to ORDER BY that column, but it is a problem since ORDER is, of course, a reserved word. The two options I see are
Rename this column (but I'd like to avoid modifying the database as much as possible)
Get around this somehow
So, in the case of 1, how would I go about renaming the column without messing up the database too much?
In the case of 2, I can't imagine what I could do, but maybe there's a trick I don't know of to get around this.
I'm using SQLite and PHP.
you just need to surround keyword collisions in `backticks`
Some databases support ` as escape character, others use […]. Looking up SQLlite's, it supports brackets:
order by [Order]
should work.
Original Question
mysql-server-6.0.10
I have this problem, I'm using the COMPRESS function to update a field with a BASE64 encoded value. The "updated" base64 string is only slightly different than the value that is currently in the database but it IS different. The only part is different is the last few bytes of the string. The problem is that mysql is seeing these values as the SAME and therefore skipping the update. It returns without error letting my program thing it did what it was told but then you go back and the data is unchagned.
For example, the first one is base64 string that was previously INSERTED to the db, the second one is what I'm trying to overwrite with:
YToxOntpOjA7YToxOntzOjE1OiJ0cmFja2luZ19udW1iZXIiO2k6MjM0MjM0MjM0MzI0MDAwO319
YToxOntpOjA7YToxOntzOjE1OiJ0cmFja2luZ19udW1iZXIiO3M6MTU6IjIzNDIzNDIzNDMyNDExMSI7fX0=
I'm running this query:
UPDATE TABLE SET fieldname=COMPRESS('YToxOntpOjA7YToxOntzOjE1OiJ0cmFja2luZ19udW1iZXIiO3M6MTU6IjIzNDIzNDIzNDMyNDExMSI7fX0=') WHERE id = 'SOMEID';
Mysql comes back with 0 rows affected.
I can reproduce this in an SQL Query window via PHPMyAdmin so I know its not a problem with code.
How can I force this to just update regardless if the strings BEGIN the same way, since it obviously inst checking the entire string? Right now my workaround is to clear the present data with one query, then run another query to update against nothing. This is inefficient though and I'm not happy with it.
First question update
I actually found out this is a result of a PHP bug with JSON_NUMERIC_CHECK!
The value was getting saved in the database properly (couldnt tell because of the compression) but when my script to go back was loading the data out of the database via JSON_ENCODE the values were getting mangled by JSON_NUMERIC_CHECK.
See the bug report I filed:
https://bugs.php.net/bug.php?id=60111
Second question update and solution
So it really turns out I was way ahead of my self on this. I was using JSON_NUMERIC_CHECK incorrectly. I was using it as a blanket solution to ensure all numeric values would be, well, numeric. The flaw in this logic is that JSON_NUMERIC_CHECK's purpose in life is to attempt to convert all numeric strings to integers, in 32-bit OS environment there is a limit to how many digits an int val can be and thus using the exponential expression as it should!
It comes down to the fact that in my system, there is a possibility of a [tracking number] could actually be an extremely long string of just numbers. JSON_NUMERIC_CHECK was doing exactly what it was suppose to do by converting this to an exponentially expressed int val.
The actual fix to this was to not use JSON_NUMERIC_CHECK and to make sure that my var types were correct where I actually needed int vals before creating the object that is later passed to the front end via JSON.
Phew, a mouthfull, but i figured if anyone else runs into this problem it might be helpful. Chao!
I'm sorry guys, nevermind, the problem is that value i'm supplying is being treated as INT instead of STRING and its over the max size of an INT so its resetting to the MAX INT and therefore being the same string.
Sometimes just thinking through it enough to post a problem on here is enough to help me figure it out :)
UPDATE:
I actually found out this is a result of a PHP bug with JSON_NUMERIC_CHECK!
The value was getting saved in the database properly (couldnt tell because of the compression) but when my script to go back was loading the data out of the database via JSON_ENCODE the values were getting mangled by JSON_NUMERIC_CHECK.
UPDATE:
I'm actually just way ahead of my self. using JSON_NUMERIC_CHECK incorrectly. My bad!
I'm trying to create a script that copies data from an old legacy mysql database into my new utf-8 formatted database.
One particular field is causing me trouble, its a latin1 field - and one record has the following in it:
!-#$%'&*£¥
When the update is performed, I get the following error message:
Zend_Db_Statement_Exception: SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\xA3' for column 'messageContent' at row 1 in C:\xampp\htdocs\portal\
library\Zend\Db\Statement\Pdo.php on line 234
Now, I'd like to strip characters that cause a problem, but other than checking ord($character) <= 126 I don't know what to do. I'm worried that my method might lose valuable data.
I am using MySQL 5.1.43 on Windows 7 - with PHP 5.3.1
Are you just trying to convert your database? If so read this link that should give you some tips on converting it, and there is a script there that might work.
Found a problem with a function deeply nested in some classes that was the problem....