| pgsql and exception [message #178100] |
Mon, 14 May 2012 06:39  |
Une Bvue
Messages: 30
Registered: March 2012
Karma: 0
|
Member |
|
|
I have an INSERT generating an exception :
ERROR: value too long for type character varying(30)
this error comes from try out usinf command line.
I'd like to print-out this error when using this database from php.
Then, i did :
$ret=$db->query($sql);
try {
while($row=$ret->fetch()){ // line 492
$rowid=$row['rowid'];
}
// do something
} catch (Exception $e) {
echo $e->getMessage()."<br />\n";
}
or using :
} catch (PDOException $e) {
echo $e->getMessage()."<br />\n";
}
From php i get :
Fatal error: Call to a member function fetch() on a non-object in
/Users/yt/Sites/landp_public/landp.php on line 492
line 492 being "while($row=$ret->fetch()){"
obviously the best way is to avoid having a varchar column with a length
lower than 30.
could i get the error from $ret ?
|
|
|
|
| Re: pgsql and exception [message #178101 is a reply to message #178100] |
Mon, 14 May 2012 07:10  |
Une Bvue
Messages: 30
Registered: March 2012
Karma: 0
|
Member |
|
|
On 14/05/12 08:39, Une Bévue wrote:
> could i get the error from $ret ?
NO, it's from $db, i got it that way :
--- code ---------------------------------------
if($ret){
// do something
}else{
// get error :
$errorInfo=$db->errorInfo();
}
------------------------------------------------
Right now i have to alter table columns with varchar(3à) to something
higher...
|
|
|
|
| Re: pgsql and exception [message #178103 is a reply to message #178100] |
Mon, 14 May 2012 07:34 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 14.05.2012 08:39, schrieb Une Bévue:
> I have an INSERT generating an exception :
> ERROR: value too long for type character varying(30)
>
> this error comes from try out usinf command line.
>
> I'd like to print-out this error when using this database from php.
>
> Then, i did :
>
> $ret=$db->query($sql);
Your code is wrong here. Every database operation should be inside the try block,
otherwise it will not be catch'ed.
/Str.
> try {
> while($row=$ret->fetch()){ // line 492
> $rowid=$row['rowid'];
> }
> // do something
> } catch (Exception $e) {
> echo $e->getMessage()."<br />\n";
> }
>
> or using :
> } catch (PDOException $e) {
> echo $e->getMessage()."<br />\n";
> }
>
> From php i get :
> Fatal error: Call to a member function fetch() on a non-object in
> /Users/yt/Sites/landp_public/landp.php on line 492
>
> line 492 being "while($row=$ret->fetch()){"
>
> obviously the best way is to avoid having a varchar column with a length lower than 30.
>
> could i get the error from $ret ?
|
|
|
|
| Re: pgsql and exception [message #178104 is a reply to message #178100] |
Mon, 14 May 2012 07:45 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 14/05/2012 8:39, Une Bévue escribió/wrote:
> I have an INSERT generating an exception :
> ERROR: value too long for type character varying(30)
>
> this error comes from try out usinf command line.
>
> I'd like to print-out this error when using this database from php.
>
> Then, i did :
>
> $ret=$db->query($sql);
> try {
> while($row=$ret->fetch()){ // line 492
> $rowid=$row['rowid'];
> }
> // do something
> } catch (Exception $e) {
> echo $e->getMessage()."<br />\n";
> }
>
> or using :
> } catch (PDOException $e) {
> echo $e->getMessage()."<br />\n";
> }
>
> From php i get :
> Fatal error: Call to a member function fetch() on a non-object in
> /Users/yt/Sites/landp_public/landp.php on line 492
>
> line 492 being "while($row=$ret->fetch()){"
>
> obviously the best way is to avoid having a varchar column with a length
> lower than 30.
This isn't a database error, it's a PHP error. The line where you define
$ret's current value:
$ret=$db->query($sql);
.... failed. Such function should return a object but it didn't
(probably, because it returned FALSE instead).
«Return Values: A query result resource on success or FALSE on failure.»
http://es.php.net/pg_query
Tips:
- Always do error checking when opening a DB connection and running a
SQL query: it's way more likely to get an error there than when
retrieving rows.
- You can inspect a variable with var_dump(), e.g.:
var_dump($ret);
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: pgsql and exception [message #178106 is a reply to message #178104] |
Mon, 14 May 2012 08:18 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 14.05.2012 09:45, schrieb "Álvaro G. Vicario":
> El 14/05/2012 8:39, Une Bévue escribió/wrote:
>> I have an INSERT generating an exception :
>> ERROR: value too long for type character varying(30)
>>
>> this error comes from try out usinf command line.
>>
>> I'd like to print-out this error when using this database from php.
>>
>> Then, i did :
>>
>> $ret=$db->query($sql);
>> try {
>> while($row=$ret->fetch()){ // line 492
>> $rowid=$row['rowid'];
>> }
>> // do something
>> } catch (Exception $e) {
>> echo $e->getMessage()."<br />\n";
>> }
>>
>> or using :
>> } catch (PDOException $e) {
>> echo $e->getMessage()."<br />\n";
>> }
>>
>> From php i get :
>> Fatal error: Call to a member function fetch() on a non-object in
>> /Users/yt/Sites/landp_public/landp.php on line 492
>>
>> line 492 being "while($row=$ret->fetch()){"
>>
>> obviously the best way is to avoid having a varchar column with a length
>> lower than 30.
>
> This isn't a database error, it's a PHP error. The line where you define $ret's
> current value:
>
> $ret=$db->query($sql);
>
> ... failed. Such function should return a object but it didn't (probably, because it
> returned FALSE instead).
>
> «Return Values: A query result resource on success or FALSE on failure.»
>
> http://es.php.net/pg_query
>
> Tips:
>
> - Always do error checking when opening a DB connection and running a SQL query: it's
> way more likely to get an error there than when retrieving rows.
>
> - You can inspect a variable with var_dump(), e.g.:
>
> var_dump($ret);
>
It is true you have to do error checking after every step, the query/execute
functions return a PDOStatement or FALSE.
But: with PDO::ERRMODE_EXCEPTION PDO does it for you, just take care to have every DB
operation in a try block.
One extra recommendation for the readers:
you should decide on which level you write the try-catch: inside your db helper
functions, or in the top level script. The savings in code using try-catch will be
more when writing one try block in your top level script.
/Str.
|
|
|
|
| Re: pgsql and exception [message #178112 is a reply to message #178103] |
Mon, 14 May 2012 12:17 |
Une Bvue
Messages: 30
Registered: March 2012
Karma: 0
|
Member |
|
|
On 14/05/12 09:34, M. Strobel wrote:
>> $ret=$db->query($sql);
> Your code is wrong here. Every database operation should be inside the try block,
> otherwise it will not be catch'ed.
right, however the prob arroses after this line.
|
|
|
|
| Re: pgsql and exception [message #178113 is a reply to message #178104] |
Mon, 14 May 2012 12:24 |
Une Bvue
Messages: 30
Registered: March 2012
Karma: 0
|
Member |
|
|
On 14/05/12 09:45, "Álvaro G. Vicario" wrote:
> This isn't a database error, it's a PHP error. The line where you define
> $ret's current value:
>
> $ret=$db->query($sql);
>
> ... failed. Such function should return a object but it didn't
> (probably, because it returned FALSE instead).
>
> «Return Values: A query result resource on success or FALSE on failure.»
right, however the PHP error is due to an SQL one :
i was attempting to put a string of length > 30 in a column of type
"varchar(30)".
right now I'm testing $ret :
if($ret){
// do normal way
} else {
// print error
}
putting try / catch around that does nothing...
|
|
|
|
| Re: pgsql and exception [message #178115 is a reply to message #178113] |
Mon, 14 May 2012 12:54 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 14.05.2012 14:24, schrieb Une Bévue:
> On 14/05/12 09:45, "Álvaro G. Vicario" wrote:
>> This isn't a database error, it's a PHP error. The line where you define
>> $ret's current value:
>>
>> $ret=$db->query($sql);
>>
>> ... failed. Such function should return a object but it didn't
>> (probably, because it returned FALSE instead).
>>
>> «Return Values: A query result resource on success or FALSE on failure.»
>
> right, however the PHP error is due to an SQL one :
> i was attempting to put a string of length > 30 in a column of type "varchar(30)".
>
> right now I'm testing $ret :
>
> if($ret){
> // do normal way
> } else {
> // print error
> }
>
> putting try / catch around that does nothing...
so you don't know what I was talking about.
See ERRMODE at http://php.net/manual/en/pdo.setattribute.php
/Str.
|
|
|
|
| Re: pgsql and exception [message #178116 is a reply to message #178113] |
Mon, 14 May 2012 12:56 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 14.05.2012 14:24, schrieb Une Bévue:
> On 14/05/12 09:45, "Álvaro G. Vicario" wrote:
>> This isn't a database error, it's a PHP error. The line where you define
>> $ret's current value:
>>
>> $ret=$db->query($sql);
>>
>> ... failed. Such function should return a object but it didn't
>> (probably, because it returned FALSE instead).
>>
>> «Return Values: A query result resource on success or FALSE on failure.»
>
> right, however the PHP error is due to an SQL one :
> i was attempting to put a string of length > 30 in a column of type "varchar(30)".
how about substr()?
/Str.
|
|
|
|
| Re: pgsql and exception [message #178117 is a reply to message #178115] |
Mon, 14 May 2012 13:03 |
Une Bvue
Messages: 30
Registered: March 2012
Karma: 0
|
Member |
|
|
On 14/05/12 14:54, M. Strobel wrote:
> so you don't know what I was talking about.
true, i forgot that, use it in a small test only.
> See ERRMODE athttp://php.net/manual/en/pdo.setattribute.php
fine thanks.
|
|
|
|
| Re: pgsql and exception [message #178118 is a reply to message #178116] |
Mon, 14 May 2012 13:26 |
Une Bvue
Messages: 30
Registered: March 2012
Karma: 0
|
Member |
|
|
On 14/05/12 14:56, M. Strobel wrote:
> how about substr()?
right I'm testing that however I'm not sure it works with accentuated
(UTF-8) characters.
for example with :
--- code ---------------------------------------------------------------
<?php
header('Content-Type:text/html; charset=utf-8');
$str="Etre ou ne pas etre, telle est est la question.";
echo $str."<br />";
echo strlen($str)."<br />";
echo substr($str, 0, 16)."<br />";
$str="Être ou ne pas être, telle est est la question."; // Accentuated
echo $str."<br />";
echo strlen($str)."<br />";
echo substr($str, 0, 16)."<br />";
?>
------------------------------------------------------------------------
I get :
Etre ou ne pas etre, telle est est la question.
47
Etre ou ne pas e
Être ou ne pas être, telle est est la question.
49
Être ou ne pas
no ending "e" with accentuated chars.
not detrimental, obviously.
|
|
|
|
| Re: pgsql and exception [message #178121 is a reply to message #178112] |
Mon, 14 May 2012 13:38 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 8:17 AM, Une Bévue wrote:
> On 14/05/12 09:34, M. Strobel wrote:
>>> $ret=$db->query($sql);
>> Your code is wrong here. Every database operation should be inside the
>> try block,
>> otherwise it will not be catch'ed.
>
> right, however the prob arroses after this line.
No, your problem occurs here. You just don't SEE it until later.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: pgsql and exception [message #178122 is a reply to message #178116] |
Mon, 14 May 2012 13:40 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 8:56 AM, M. Strobel wrote:
> Am 14.05.2012 14:24, schrieb Une Bévue:
>> On 14/05/12 09:45, "Álvaro G. Vicario" wrote:
>>> This isn't a database error, it's a PHP error. The line where you define
>>> $ret's current value:
>>>
>>> $ret=$db->query($sql);
>>>
>>> ... failed. Such function should return a object but it didn't
>>> (probably, because it returned FALSE instead).
>>>
>>> «Return Values: A query result resource on success or FALSE on failure.»
>>
>> right, however the PHP error is due to an SQL one :
>> i was attempting to put a string of length> 30 in a column of type "varchar(30)".
>
> how about substr()?
>
> /Str.
>
>
No - you do NOT want to change the user's input! What if it is, for
instance, a rather long user name? Or an email address?
The input field should be limited to the amount of data allowed (30
characters, in this case). And if the data coming in are still too
long, reject it with a message to the user.
Allow the user to determine what he/she wants to put in the field.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: pgsql and exception [message #178126 is a reply to message #178122] |
Mon, 14 May 2012 15:02 |
Une Bvue
Messages: 30
Registered: March 2012
Karma: 0
|
Member |
|
|
On 14/05/12 15:40, Jerry Stuckle wrote:
> No - you do NOT want to change the user's input! What if it is, for
> instance, a rather long user name? Or an email address?
>
> The input field should be limited to the amount of data allowed (30
> characters, in this case). And if the data coming in are still too
> long, reject it with a message to the user.
Yes right, specially for a link, in fact I've altered the tables columns
for varchar(256), and I'll do something in case the user entered
something longer...
|
|
|
|
| Re: pgsql and exception [message #178127 is a reply to message #178126] |
Mon, 14 May 2012 15:19 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
El 14/05/2012 17:02, Une Bévue escribió:
>
> Yes right, specially for a link, in fact I've altered the tables columns
> for varchar(256), and I'll do something in case the user entered
> something longer...
You have to take care of not getting a big size database? because, if
you have space and could be more genereous... I think is better idea put
a bigger number.
Links, You mean URL? have no limit. It don't need to be longs, but it
can. There is any requirement of use a "small" varchar(256) for this field?
IF there is no limitation or requirement, perhaps is better to put
enough space to avoid problems. varchar(1024) could no make a big
diference if you don't have a really enormous amount of data.
Greetings
|
|
|
|
| Re: pgsql and exception [message #178133 is a reply to message #178127] |
Mon, 14 May 2012 18:46 |
Une Bvue
Messages: 30
Registered: March 2012
Karma: 0
|
Member |
|
|
On 14/05/12 17:19, Shake wrote:
> Links, You mean URL? have no limit. It don't need to be longs, but it
> can. There is any requirement of use a "small" varchar(256) for this field?
>
> IF there is no limitation or requirement, perhaps is better to put
> enough space to avoid problems. varchar(1024) could no make a big
> diference if you don't have a really enormous amount of data.
Yes I mean url for link, a simple google maps URL gave me strlen($url) = 329
I have to be more generous...
|
|
|
|
| Re: pgsql and exception [message #178135 is a reply to message #178133] |
Mon, 14 May 2012 18:55 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 2:46 PM, Une Bévue wrote:
> On 14/05/12 17:19, Shake wrote:
>> Links, You mean URL? have no limit. It don't need to be longs, but it
>> can. There is any requirement of use a "small" varchar(256) for this
>> field?
>>
>> IF there is no limitation or requirement, perhaps is better to put
>> enough space to avoid problems. varchar(1024) could no make a big
>> diference if you don't have a really enormous amount of data.
>
> Yes I mean url for link, a simple google maps URL gave me strlen($url) =
> 329
>
> I have to be more generous...
There is no defined limit as to the length of a URL. However, most
browser can handle well over 1K, and servers 4K or more. I generally
use a 4K VARCHAR for URLs.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: pgsql and exception [message #178136 is a reply to message #178133] |
Mon, 14 May 2012 19:48 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 14-05-2012 20:46, Une Bévue wrote:
> On 14/05/12 17:19, Shake wrote:
>> Links, You mean URL? have no limit. It don't need to be longs, but it
>> can. There is any requirement of use a "small" varchar(256) for this
>> field?
>>
>> IF there is no limitation or requirement, perhaps is better to put
>> enough space to avoid problems. varchar(1024) could no make a big
>> diference if you don't have a really enormous amount of data.
>
> Yes I mean url for link, a simple google maps URL gave me strlen($url) =
> 329
>
> I have to be more generous...
not too generous ;)
http://dev.mysql.com/doc/refman/5.5/en/char.html
"In contrast to CHAR, VARCHAR values are stored as a one-byte or
two-byte length prefix plus data. The length prefix indicates the number
of bytes in the value. A column uses one length byte if values require
no more than 255 bytes, two length bytes if values may require more than
255 bytes. "
Changing the length from 256 to 1024, or even 2048, should only make a
difference if you store a lot of those lengthy urls...
|
|
|
|
| Re: pgsql and exception [message #178137 is a reply to message #178118] |
Mon, 14 May 2012 20:33 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 14.05.2012 15:26, schrieb Une Bévue:
> On 14/05/12 14:56, M. Strobel wrote:
>> how about substr()?
> right I'm testing that however I'm not sure it works with accentuated (UTF-8)
> characters.
>
> for example with :
> --- code ---------------------------------------------------------------
> <?php
> header('Content-Type:text/html; charset=utf-8');
>
> $str="Etre ou ne pas etre, telle est est la question.";
> echo $str."<br />";
> echo strlen($str)."<br />";
> echo substr($str, 0, 16)."<br />";
>
> $str="Être ou ne pas être, telle est est la question."; // Accentuated
> echo $str."<br />";
> echo strlen($str)."<br />";
> echo substr($str, 0, 16)."<br />";
>
> ?>
> ------------------------------------------------------------------------
>
> I get :
> Etre ou ne pas etre, telle est est la question.
> 47
> Etre ou ne pas e
> Être ou ne pas être, telle est est la question.
> 49
> Être ou ne pas
>
Je programme donc je suis.
You get the string length in bytes, which is okay when you want to store it in a
length limited field. If you want the length for display formatting this is a problem.
Good programming languages now make a difference between string length in bytes and
string length in characters.
Did not find this one in PHP.
/Str.
|
|
|
|
| Re: pgsql and exception [message #178149 is a reply to message #178135] |
Tue, 15 May 2012 06:00 |
Une Bvue
Messages: 30
Registered: March 2012
Karma: 0
|
Member |
|
|
On 14/05/12 20:55, Jerry Stuckle wrote:
> There is no defined limit as to the length of a URL. However, most
> browser can handle well over 1K, and servers 4K or more. I generally
> use a 4K VARCHAR for URLs.
OK, thanks, I'll change that to 4K
|
|
|
|
| Re: pgsql and exception [message #178150 is a reply to message #178118] |
Tue, 15 May 2012 07:32 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 14.05.2012 15:26, schrieb Une Bévue:
> On 14/05/12 14:56, M. Strobel wrote:
>> how about substr()?
> right I'm testing that however I'm not sure it works with accentuated (UTF-8)
> characters.
>
> for example with :
> --- code ---------------------------------------------------------------
> <?php
> header('Content-Type:text/html; charset=utf-8');
>
> $str="Etre ou ne pas etre, telle est est la question.";
> echo $str."<br />";
> echo strlen($str)."<br />";
> echo substr($str, 0, 16)."<br />";
>
> $str="Être ou ne pas être, telle est est la question."; // Accentuated
> echo $str."<br />";
> echo strlen($str)."<br />";
> echo substr($str, 0, 16)."<br />";
>
> ?>
> ------------------------------------------------------------------------
>
> I get :
> Etre ou ne pas etre, telle est est la question.
> 47
> Etre ou ne pas e
> Être ou ne pas être, telle est est la question.
> 49
> Être ou ne pas
>
If you don't know the reason the accented version is longer, read about utf-8.
/Str.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]