Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #6011 > unrolled thread

pgsql and exception

Back to article view | Back to comp.lang.php

Contents

  pgsql and exception Une Bévue <unbewusstsein@fai.invalid> - 2012-05-14 08:39 +0200
    Re: pgsql and exception Une Bévue <unbewusstsein@fai.invalid> - 2012-05-14 09:10 +0200
    Re: pgsql and exception "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-05-14 09:34 +0200
      Re: pgsql and exception Une Bévue <unbewusstsein@fai.invalid> - 2012-05-14 14:17 +0200
        Re: pgsql and exception Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 09:38 -0400
          Re: pgsql and exception Une Bévue <unbewusstsein@fai.invalid> - 2012-05-14 16:59 +0200
    Re: pgsql and exception "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-05-14 09:45 +0200
      Re: pgsql and exception "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-05-14 10:18 +0200
      Re: pgsql and exception Une Bévue <unbewusstsein@fai.invalid> - 2012-05-14 14:24 +0200
        Re: pgsql and exception "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-05-14 14:54 +0200
          Re: pgsql and exception Une Bévue <unbewusstsein@fai.invalid> - 2012-05-14 15:03 +0200
        Re: pgsql and exception "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-05-14 14:56 +0200
          Re: pgsql and exception Une Bévue <unbewusstsein@fai.invalid> - 2012-05-14 15:26 +0200
            Re: pgsql and exception "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-05-14 22:33 +0200
            Re: pgsql and exception "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-05-15 09:32 +0200
          Re: pgsql and exception Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 09:40 -0400
            Re: pgsql and exception Une Bévue <unbewusstsein@fai.invalid> - 2012-05-14 17:02 +0200
              Re: pgsql and exception Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 17:19 +0200
                Re: pgsql and exception Une Bévue <unbewusstsein@fai.invalid> - 2012-05-14 20:46 +0200
                  Re: pgsql and exception Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:55 -0400
                    Re: pgsql and exception Une Bévue <unbewusstsein@fai.invalid> - 2012-05-15 08:00 +0200
                  Re: pgsql and exception Luuk <luuk@invalid.lan> - 2012-05-14 21:48 +0200

Page 1 of 2  [1] 2  Next page →

#6011 — pgsql and exception

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 ?

[toc] | [next] | [standalone]

#6012

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...

[toc] | [prev] | [next] | [standalone]

#6014

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 ?

[toc] | [prev] | [next] | [standalone]

#6023

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.

[toc] | [prev] | [next] | [standalone]

#6032

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6036

On 14/05/12 15:38, Jerry Stuckle wrote:
> No, your problem occurs here.  You just don't SEE it until later.

OK, right.

[toc] | [prev] | [next] | [standalone]

#6015

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
--

[toc] | [prev] | [next] | [standalone]

#6017

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.

[toc] | [prev] | [next] | [standalone]

#6024

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...

[toc] | [prev] | [next] | [standalone]

#6026

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.

[toc] | [prev] | [next] | [standalone]

#6028

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.

[toc] | [prev] | [next] | [standalone]

#6027

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.

[toc] | [prev] | [next] | [standalone]

#6029

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.

[toc] | [prev] | [next] | [standalone]

#6048

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.

[toc] | [prev] | [next] | [standalone]

#6067

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.

[toc] | [prev] | [next] | [standalone]

#6033

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6037

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...

[toc] | [prev] | [next] | [standalone]

#6038

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

[toc] | [prev] | [next] | [standalone]

#6044

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...

[toc] | [prev] | [next] | [standalone]

#6046

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web