Re: Validating Data
From: joel garry <joel-garry_at_home.com>
Date: Fri, 24 Feb 2012 08:57:48 -0800 (PST)
Message-ID: <ecc99585-936e-4427-8f8e-93ee153ae10c_at_ub4g2000pbc.googlegroups.com>
On Feb 24, 7:19 am, Mark D Powell <Mark.Powe..._at_hp.com> wrote:
> On Feb 24, 1:41 am, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
>
>
>
> > On Thu, 23 Feb 2012 06:51:33 -0800, ExecMan wrote:
> > > Hi,
>
> > > We have a stored procedure called from a PHP web application. The
> > > parameters received are of VARCHAR2, but we've seen non-printable
> > > characters come through, which throw errors.
>
> > > If there any type of RegExp of anything I can run to detect if the
> > > parameter contains non-ascii characters? (Granted, application should
> > > check this before sending it to the database, but I did not write the
> > > application).
>
> > > Thanks!
>
> > With all due respect, why would you use a database for such thing? Oracle
> > has regexp functions but PHP as a scripting language, loosely based on
> > Perl has a really good implementation of a very recent PCRE version.
> > What you need is here:http://us.php.net/manual/en/regexp.reference.character-classes.php
>
> > The class that you need is [:print:] which includes all printable
> > characters. I imagine that a scripting language, purposely built to be
> > similar Perl, must process characters much faster than a database.
>
> > --http://mgogala.byethost5.com
>
> I will agree with Mladen in that I think applications have the
> responsibility to edit their data prior to attempting to input it into
> the database though I do not necissarily object to using database
> provided SQL functions to handle some of the work such as trimming
> trailing spaces or specifing the input date format. But most
> validation activities should take place prior to insert or update.
>
> HTH -- Mark D Powell --
Date: Fri, 24 Feb 2012 08:57:48 -0800 (PST)
Message-ID: <ecc99585-936e-4427-8f8e-93ee153ae10c_at_ub4g2000pbc.googlegroups.com>
On Feb 24, 7:19 am, Mark D Powell <Mark.Powe..._at_hp.com> wrote:
> On Feb 24, 1:41 am, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
>
>
>
> > On Thu, 23 Feb 2012 06:51:33 -0800, ExecMan wrote:
> > > Hi,
>
> > > We have a stored procedure called from a PHP web application. The
> > > parameters received are of VARCHAR2, but we've seen non-printable
> > > characters come through, which throw errors.
>
> > > If there any type of RegExp of anything I can run to detect if the
> > > parameter contains non-ascii characters? (Granted, application should
> > > check this before sending it to the database, but I did not write the
> > > application).
>
> > > Thanks!
>
> > With all due respect, why would you use a database for such thing? Oracle
> > has regexp functions but PHP as a scripting language, loosely based on
> > Perl has a really good implementation of a very recent PCRE version.
> > What you need is here:http://us.php.net/manual/en/regexp.reference.character-classes.php
>
> > The class that you need is [:print:] which includes all printable
> > characters. I imagine that a scripting language, purposely built to be
> > similar Perl, must process characters much faster than a database.
>
> > --http://mgogala.byethost5.com
>
> I will agree with Mladen in that I think applications have the
> responsibility to edit their data prior to attempting to input it into
> the database though I do not necissarily object to using database
> provided SQL functions to handle some of the work such as trimming
> trailing spaces or specifing the input date format. But most
> validation activities should take place prior to insert or update.
>
> HTH -- Mark D Powell --
ExecMan, I've been wondering, what are the "non-printable" characters? There are non-ASCII characters that are eminently printable, even in a 7 bit db, could this just be an NLS or database characterset problem? What are your settings all around? What does a dump of the character tell you the value is? What are the errors?
I have seen several situations where "we'll never have non-English characters," until they do. I've also seen issues with going across platforms, such as ^Z at the end of docs causing loads of problems, solved by a simple dos2ux conversion or sed.
jg
-- _at_home.com is bogus. Joel'); drop table students;--Received on Fri Feb 24 2012 - 10:57:48 CST