php-general Digest 27 Jan 2012 17:09:37 -0000 Issue 7665
Topics (messages 316395 through 316413):
Re: sql injection protection
316395 by: Haluk Karamete
316409 by: Maciek Sokolewicz
316410 by: Jim Lucas
316412 by: Haluk Karamete
File upload in map drive with PHP
316396 by: Mehmet YAYLA
316397 by: Jim Giner
316399 by: Mehmet YAYLA
316400 by: Jim Giner
316401 by: Stuart Dallas
316411 by: Jim Lucas
Getting Column Names from an AS400 Database
316398 by: Cheryl Sullivan
316404 by: Jim Giner
316405 by: Cheryl Sullivan
316406 by: Maciek Sokolewicz
316407 by: Maciek Sokolewicz
316408 by: Alejandro Michelin Salomon
Re: Autoloading
316402 by: Stuart Dallas
316403 by: Floyd Resler
Re: differences in between these env. variables
316413 by: Tedd Sperling
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
when we do b64e and then back b64d, you are saying. we get the org
input all as clear text but this time as a string. because it is now a
string, "(which by definition can not be executed)"
what's the difference between b64e+b64d vs (string) casting then? if
you were to cast the original input into string using (string),
wouldn't you be in the same shoes?
also on another note, if you know the userinput is in UTF-8, ( you
verify that by running mb_detect_encoding($str, 'UTF-8', true); ), is
there a situation where you think mysql_real_escape_string would fail
in SQLINjection against string based user input ? The reason I ask
this about specifically for strings is because it is fairly easy to
validate againsts integers,floats,booleans using the built in
validation filters.... my biggest issue is on strings...
also what do you think about filter_sanitize_string.
and finally, where do you think PHP community plus Rasmus is having a
hard time implementing what you have in mind - that is a one liner
that will do the inline string interpolation you are talking about..
what's the issue that it hasn't been done before?
On Tue, Jan 24, 2012 at 1:45 PM, Alex Nikitin <niks...@gmail.com> wrote:
> You don't need to store it in the database as b64, just undo the
> encoding into your inputs
>
> for the purpose of the explanation, this is language independent
>
> b64e - encoding function
> b64d - decoding function
>
>
> pseudo code
>
> given:
> bad_num = ') union select * from foo --'
> bad_str = ""
> good_num = 123456
> good_str = "some searchable text"
>
> the b64 way:
> bad_num=b64e(bad_num)
> ...
> good_str=b64e(good_str)
>
>
> inserts:
> query("insert into foo (num, str) values (b64d(\""+bad_num+"\"),
> b64d(\""+bad_str+"\"))");
> query("insert into foo (num, str) values (b64d(\""+good_num+"\"),
> b64d(\""+good_str+"\"))");
>
> Can you see that this will safely insert clear text into the database?
> This is because when you convert anything from b64, it will return
> from the function as a string and will not be executed as code...
>
>
> Now let's try a search:
> bad_num= '1 or 2 not like 5'
> bad_str = "' or \"40oz\" like \"40oz\""
>
> again we:
> bad_num=b64e(bad_num)
> bad_str=b64e(bad_str)
>
> then we can do a full text search:
> query("select * from foo where match(str) against(b64d(\""+bad_str+"\"))")
> or even a number search
> query("select * from foo where num=b64d(\""+bad_num+"\")")
>
> again this is possible because no matter what you put in bad num, it
> will never be able to make post b64e bad_num look like code, just
> looks like junk, until b64d converts it to a string (which by
> definition can not be executed)
>
> make sense now?
>
>
> by check i mean, run utf8_decode for example...
>
>
> Problem is, that i can tell you how to write the most secure code, but
> if it's hard, or worse yet creates more problems than it solves
> (seemingly), nobody other than a few individuals with some passion for
> security will ever find the code useful. We need to fix this on the
> language level, then we can go around and tell programmers how to do
> it right. I mean imagine telling a programmer, that something that
> takes them 2 lines of code now, can be done much more securely in 5-7,
> and it creates code that doesn't read linearly... Most programmers
> will just ignore you. I want to say, "hey programmer, what you do in 2
> lines of code, you can do in 1 and make it impossible to inject into",
> then, then people will listen, maybe... This is where inline string
> interpolation syntax comes in, but it is not implemented in any
> programming languages, sadly actually. This is what i want to talk to
> Rasmus about.
--- End Message ---
--- Begin Message ---
On 26-01-2012 15:46, Haluk Karamete wrote:
when we do b64e and then back b64d, you are saying. we get the org
input all as clear text but this time as a string. because it is now a
string, "(which by definition can not be executed)"
what's the difference between b64e+b64d vs (string) casting then? if
you were to cast the original input into string using (string),
wouldn't you be in the same shoes?
No, it's not. The problem here is that we're using 2 different systems,
which have to talk to eachother. They do this via strings.
If you send 'SELECT a FROM b', for PHP that's a string. It doesn't know
or even care if this is SQL or what you want to do with it. To PHP it's
just a string.
Once it gets to MySQL however, it will look at that string, parse it as
SQL and execute it.
Now, if we use:
'SELECT a FROM b; DROP TABLE b'
for PHP, it will still be just a string. Nothing special.
For MySQL however, it will have turned into 2 different operations,
which will both be executed. It will first SELECT a FROM b, and then
DROP TABLE b.
Can this be resolved by casting the whole query to a string in PHP? No.
It's already a string.
However, if you base64_encode a part of the query (the variable part
that you're afraid might get replaced by malicious code), it will appear
as a string to MySQL. It will recieve the following:
SELECT a FROM b WHERE c='MSc7RFJPUCBUQUJMRSBiIFdIRVJFIDE9JzE=';
instead of:
SELECT a FROM b WHERE c='1';DROP TABLE b WHERE 1='1';
To PHP, both are still strings. But to MySQL, the first is an operation
which SELECTs a from b where c has a certain value. The second, does the
same, but also drops the table (! WHOA! we Don't want that!!).
Of course, if we change the code to:
SELECT a FROM b WHERE
c=BASE64DECODE('MSc7RFJPUCBUQUJMRSBiIFdIRVJFIDE9JzE=');
It will select based on the STRING "1';DROP TABLE b WHERE 1='1" and will
not execute it, since it did not recieve it as executable code.
Do you finally understand the difference?
also on another note, if you know the userinput is in UTF-8, ( you
verify that by running mb_detect_encoding($str, 'UTF-8', true); )
This doesn't guarantee anything. You can't see the encoding on a bare
string. You can guess what it might be (using a function such as
mb_detect_encoding), but it might very well be wrong.
If I send you a string like 'abcdef', it may be detected as being ANSII,
ISO-8859-11, ISO-8859-16, and a million others. Why? Because encoding is
just a way of saying "value X in this string represents character Y",
but to know that, you first need to know what codepage / encoding
belongs to it. If you don't know that, value 2148 might mean 'C' or 'F'
or 'PO'. You don't know, and you don't have any way of figuring this
out. That is why it is CRITICAL to know what encoding is being used.
If a UTF-7 encoded string is provided, it may look like a string of crap
to you. But when it is interpreted as being in UTF-8 it might suddenly
completely change meaning, and contain malicious code. The string itself
doesn't change at all, just the interpretation of the string.
When starting a connection, you should make sure that the encoding it
works with is the same you're using to construct your strings. So if
you're working in UTF-7, make sure MySQL is aswell. Otherwise, you have
to make sure to manually recode your strings from UTF-7 to UTF-8.
Hopefuly that makes it more clear to you.
, is
there a situation where you think mysql_real_escape_string would fail
in SQLINjection against string based user input ? The reason I ask
this about specifically for strings is because it is fairly easy to
validate againsts integers,floats,booleans using the built in
validation filters.... my biggest issue is on strings...
also what do you think about filter_sanitize_string.
and finally, where do you think PHP community plus Rasmus is having a
hard time implementing what you have in mind - that is a one liner
that will do the inline string interpolation you are talking about..
what's the issue that it hasn't been done before?
There are many ways of getting around the functions mentioned above.
Personally I have little experience with HOW you can do it (although
I've been forced to patch holes found due to the fact that we did rely
on it though). You can search the internet to find out how. We can't
really help you there, we can only advise you (as has been done a
million times already, though you don't seem to be able to accept the
recommendation). If you decide not to accept the recommendation, then
don't, and just use your own way. It may bite you after a while though.
Security issues like the one mentioned above are notoriously difficult
to eliminate effectively; oneliners rarely if ever suffice.
- Tul
--- End Message ---
--- Begin Message ---
On 01/26/2012 06:46 AM, Haluk Karamete wrote:
when we do b64e and then back b64d, you are saying. we get the org
input all as clear text but this time as a string. because it is now a
string, "(which by definition can not be executed)"
what's the difference between b64e+b64d vs (string) casting then? if
you were to cast the original input into string using (string),
wouldn't you be in the same shoes?
Re-read his example. He encodes the data in PHP. But decodes the data
in SQL. So, if you echo the SQL statement, you would see a base64
encoded string that SQL then decodes.
also on another note, if you know the userinput is in UTF-8, ( you
verify that by running mb_detect_encoding($str, 'UTF-8', true); ), is
there a situation where you think mysql_real_escape_string would fail
in SQLINjection against string based user input ? The reason I ask
this about specifically for strings is because it is fairly easy to
validate againsts integers,floats,booleans using the built in
validation filters.... my biggest issue is on strings...
also what do you think about filter_sanitize_string.
read this:
http://www.php.net/manual/en/filter.filters.sanitize.php
Then read this:
http://www.php.net/manual/en/filter.filters.flags.php
It seems to me that filter_sanitize_string does not deal with anything
other then ASCII.
YMMV
and finally, where do you think PHP community plus Rasmus is having a
hard time implementing what you have in mind - that is a one liner
that will do the inline string interpolation you are talking about..
what's the issue that it hasn't been done before?
On Tue, Jan 24, 2012 at 1:45 PM, Alex Nikitin<niks...@gmail.com> wrote:
You don't need to store it in the database as b64, just undo the
encoding into your inputs
for the purpose of the explanation, this is language independent
b64e - encoding function
b64d - decoding function
pseudo code
given:
bad_num = ') union select * from foo --'
bad_str = ""
good_num = 123456
good_str = "some searchable text"
the b64 way:
bad_num=b64e(bad_num)
...
good_str=b64e(good_str)
inserts:
query("insert into foo (num, str) values (b64d(\""+bad_num+"\"),
b64d(\""+bad_str+"\"))");
query("insert into foo (num, str) values (b64d(\""+good_num+"\"),
b64d(\""+good_str+"\"))");
Can you see that this will safely insert clear text into the database?
This is because when you convert anything from b64, it will return
from the function as a string and will not be executed as code...
Now let's try a search:
bad_num= '1 or 2 not like 5'
bad_str = "' or \"40oz\" like \"40oz\""
again we:
bad_num=b64e(bad_num)
bad_str=b64e(bad_str)
then we can do a full text search:
query("select * from foo where match(str) against(b64d(\""+bad_str+"\"))")
or even a number search
query("select * from foo where num=b64d(\""+bad_num+"\")")
again this is possible because no matter what you put in bad num, it
will never be able to make post b64e bad_num look like code, just
looks like junk, until b64d converts it to a string (which by
definition can not be executed)
make sense now?
by check i mean, run utf8_decode for example...
Problem is, that i can tell you how to write the most secure code, but
if it's hard, or worse yet creates more problems than it solves
(seemingly), nobody other than a few individuals with some passion for
security will ever find the code useful. We need to fix this on the
language level, then we can go around and tell programmers how to do
it right. I mean imagine telling a programmer, that something that
takes them 2 lines of code now, can be done much more securely in 5-7,
and it creates code that doesn't read linearly... Most programmers
will just ignore you. I want to say, "hey programmer, what you do in 2
lines of code, you can do in 1 and make it impossible to inject into",
then, then people will listen, maybe... This is where inline string
interpolation syntax comes in, but it is not implemented in any
programming languages, sadly actually. This is what i want to talk to
Rasmus about.
--
Jim Lucas
http://www.cmsws.com/
http://www.cmsws.com/examples/
http://www.bendsource.com/
--- End Message ---
--- Begin Message ---
>>Re-read his example. He encodes the data in PHP. But decodes the data in
>>SQL. So, if you echo the SQL statement, you would see a base64 encoded
>>string that SQL then decodes.
Got it this time! Up until reading your reply, I was reading Alex's
example with my pseudo-code glasses. I did not realize that the
decoding was being done by SQL! I though it was still in PHP. And
that's where I got confused with the hey why not string casting it
then and got into what's the difference situation. But, you were laser
sharp on that! Thanks a bunch!
>> as to the other issue, the one with utf-8 and mb_detect_encoding, not
>> working for it - cause there are ways of getting around. I still don't get
>> it. First q comes to mind, why the heck use mb_detect_encoding then if it
>> can be hacked around? see what I'm saying. but i don't want to go off on a
>> tangent.. all i'm trying to do is to safely protect myself from a possible
>> sql injection by using the available filters and sanitizations and
>> techniques but without the PDO. That's the requirement. No PDO. From the
>> earlier recommendations, I understand PDO is the way to go - cause it
>> effectively separates the sql code from the user input to make sure user
>> input does not get executed.. that explanation ... i get that... no problems
>> there... yes, do use PDO... but my question is not what's the safest way in
>> general?. But rather, what's the safest way without the PDO? Without the
>> PDO, it seems like b64'ing it will do the job! And since the data will be
>> stored as clear text, the searches against that data will also work too. I
>> can take this implementation and build my library function based on that -
>> instead of making it
1- first check if the in user string is in utf-8,
2- reject the input if not in utf-8
3- accept the input if utf-8 and apply the applicable filters to it
starting with filter_sanitize_string
4- and on top of that, also mysql_real_escape it
but from what i understand, you guys are saying just don't do this,
because it may be overcome and that's not because of the fact
filter_sanitize_string or mysql_real_escape_string is not effective,
but because of the fact that there is NO WAY to reliably detect
whether the incoming user input is in utf-8 or not.
On Thu, Jan 26, 2012 at 9:14 AM, Jim Lucas <li...@cmsws.com> wrote:
> On 01/26/2012 06:46 AM, Haluk Karamete wrote:
>>
>> when we do b64e and then back b64d, you are saying. we get the org
>> input all as clear text but this time as a string. because it is now a
>> string, "(which by definition can not be executed)"
>>
>> what's the difference between b64e+b64d vs (string) casting then? if
>> you were to cast the original input into string using (string),
>> wouldn't you be in the same shoes?
>
>
> Re-read his example. He encodes the data in PHP. But decodes the data in
> SQL. So, if you echo the SQL statement, you would see a base64 encoded
> string that SQL then decodes.
>
>
>>
>> also on another note, if you know the userinput is in UTF-8, ( you
>> verify that by running mb_detect_encoding($str, 'UTF-8', true); ), is
>> there a situation where you think mysql_real_escape_string would fail
>> in SQLINjection against string based user input ? The reason I ask
>> this about specifically for strings is because it is fairly easy to
>> validate againsts integers,floats,booleans using the built in
>> validation filters.... my biggest issue is on strings...
>>
>> also what do you think about filter_sanitize_string.
>
>
> read this:
>
> http://www.php.net/manual/en/filter.filters.sanitize.php
>
> Then read this:
>
> http://www.php.net/manual/en/filter.filters.flags.php
>
> It seems to me that filter_sanitize_string does not deal with anything other
> then ASCII.
>
> YMMV
>
>
>>
>> and finally, where do you think PHP community plus Rasmus is having a
>> hard time implementing what you have in mind - that is a one liner
>> that will do the inline string interpolation you are talking about..
>> what's the issue that it hasn't been done before?
>>
>>
>>
>> On Tue, Jan 24, 2012 at 1:45 PM, Alex Nikitin<niks...@gmail.com> wrote:
>>>
>>> You don't need to store it in the database as b64, just undo the
>>> encoding into your inputs
>>>
>>> for the purpose of the explanation, this is language independent
>>>
>>> b64e - encoding function
>>> b64d - decoding function
>>>
>>>
>>> pseudo code
>>>
>>> given:
>>> bad_num = ') union select * from foo --'
>>> bad_str = ""
>>> good_num = 123456
>>> good_str = "some searchable text"
>>>
>>> the b64 way:
>>> bad_num=b64e(bad_num)
>>> ...
>>> good_str=b64e(good_str)
>>>
>>>
>>> inserts:
>>> query("insert into foo (num, str) values (b64d(\""+bad_num+"\"),
>>> b64d(\""+bad_str+"\"))");
>>> query("insert into foo (num, str) values (b64d(\""+good_num+"\"),
>>> b64d(\""+good_str+"\"))");
>>>
>>> Can you see that this will safely insert clear text into the database?
>>> This is because when you convert anything from b64, it will return
>>> from the function as a string and will not be executed as code...
>>>
>>>
>>> Now let's try a search:
>>> bad_num= '1 or 2 not like 5'
>>> bad_str = "' or \"40oz\" like \"40oz\""
>>>
>>> again we:
>>> bad_num=b64e(bad_num)
>>> bad_str=b64e(bad_str)
>>>
>>> then we can do a full text search:
>>> query("select * from foo where match(str)
>>> against(b64d(\""+bad_str+"\"))")
>>> or even a number search
>>> query("select * from foo where num=b64d(\""+bad_num+"\")")
>>>
>>> again this is possible because no matter what you put in bad num, it
>>> will never be able to make post b64e bad_num look like code, just
>>> looks like junk, until b64d converts it to a string (which by
>>> definition can not be executed)
>>>
>>> make sense now?
>>>
>>>
>>> by check i mean, run utf8_decode for example...
>>>
>>>
>>> Problem is, that i can tell you how to write the most secure code, but
>>> if it's hard, or worse yet creates more problems than it solves
>>> (seemingly), nobody other than a few individuals with some passion for
>>> security will ever find the code useful. We need to fix this on the
>>> language level, then we can go around and tell programmers how to do
>>> it right. I mean imagine telling a programmer, that something that
>>> takes them 2 lines of code now, can be done much more securely in 5-7,
>>> and it creates code that doesn't read linearly... Most programmers
>>> will just ignore you. I want to say, "hey programmer, what you do in 2
>>> lines of code, you can do in 1 and make it impossible to inject into",
>>> then, then people will listen, maybe... This is where inline string
>>> interpolation syntax comes in, but it is not implemented in any
>>> programming languages, sadly actually. This is what i want to talk to
>>> Rasmus about.
>>
>>
>
>
> --
> Jim Lucas
>
> http://www.cmsws.com/
> http://www.cmsws.com/examples/
> http://www.bendsource.com/
--- End Message ---
--- Begin Message ---
Hello everyone,
I've a question.
I'm using map drive for file upload but dos'nt work.
How can i do file upload map drive with php?
Best Regards.
--- End Message ---
--- Begin Message ---
Do you mean you are trying to do an upload of a file on a mapped drive, such
as a network drive? Is this upload using an html form with an <input
type="file"> tag?
--- End Message ---
--- Begin Message ---
I'm using code this bellow.
<?
if (!empty($_GET["upload"])) {
$uploaddir ="x:\\file/";
$uploadfile = $_FILES['userfile']['name'];
print "<pre>";
if (move_uploaded_file($_FILES['userfile']['tmp_name'],
"$uploaddir"."$uploadfile")) {
echo "Dosya basari ile yüklendi. ";
} else {
print "Dosya yüklenemedi. Tekrar deneyiniz";
}
print "</pre>";
}
?>
<form enctype="multipart/form-data" action="upload_file.php?upload=1"
method="post"> <input type="hidden" name="MAX_FILE_SIZE" value="30000" />
Select image: <input name="userfile" type="file"/>
<input type="submit" value="Upload" />
> To: php-gene...@lists.php.net
> From: jim.gi...@albanyhandball.com
> Date: Thu, 26 Jan 2012 10:00:29 -0500
> Subject: [PHP] Re: File upload in map drive with PHP
>
> Do you mean you are trying to do an upload of a file on a mapped drive, such
> as a network drive? Is this upload using an html form with an <input
> type="file"> tag?
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
You're using a GET in your script when your form is a POST.
--- End Message ---
--- Begin Message ---
On 26 Jan 2012, at 15:10, Mehmet YAYLA wrote:
>
> I'm using code this bellow.
>
>
> <?
> if (!empty($_GET["upload"])) {
> $uploaddir ="x:\\file/";
>
> $uploadfile = $_FILES['userfile']['name'];
>
> print "<pre>";
>
> if (move_uploaded_file($_FILES['userfile']['tmp_name'],
> "$uploaddir"."$uploadfile")) {
>
> echo "Dosya basari ile yüklendi. ";
>
>
> } else {
> print "Dosya yüklenemedi. Tekrar deneyiniz";
>
> }
> print "</pre>";
> }
>
> ?>
>
> <form enctype="multipart/form-data" action="upload_file.php?upload=1"
> method="post"> <input type="hidden" name="MAX_FILE_SIZE" value="30000" />
> Select image: <input name="userfile" type="file"/>
> <input type="submit" value="Upload" />
The drive needs to be mapped for the internet user (usually IUSR_machinename I
think), otherwise that drive won't exist.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On 01/26/2012 07:13 AM, Jim Giner wrote:
You're using a GET in your script when your form is a POST.
and if you look at the method value you will see that he is passing
upload=1 in the URL. Which would be seen as a GET value.
--
Jim Lucas
http://www.cmsws.com/
http://www.cmsws.com/examples/
http://www.bendsource.com/
--- End Message ---
--- Begin Message ---
Can someone tell me why the following code:
//----------------------------------------------------
$q = sprintf("SELECT * FROM DB#LIBNAME.TABLENAME");
$conn = new COM ("ADODB.Connection")
or die("Cannot start ADO");
$connStr = "Provider=IBMDA400;Password=XXXXXX;User ID=XXXX;Data
Source=999.99.1.100;Transport Product=Client Access;SSL=DEFAULT";
$conn->open($connStr);
$rs = $conn->execute($q);
$outval = odbc_columns($conn, "DB#LIBNAME", "%", "TABLENAME", "%");
//----------------------------------------------------
results in this error being generated on the $outval line?
odbc_columns() expects parameter 1 to be resource, object given in
D:\WAMP\www\directory\filename.php on line 13
Cheryl L. Sullivan
Interface Analyst / Web Developer
Sacred Heart Hospital (www.shh.org <http://www.shh.org/> )
421 Chew Street * Allentown, PA 18102
Office: 610-776-4784
Sacred Heart Hospital - 2011 Greater Lehigh Valley Chamber of Commerce
Business of the Year <http://www.shh.org/news/release.asp?id=145>
Notice: This communication, including attachments, may contain information that
is confidential and protected. It constitutes non-public information intended
to be conveyed only to the designated recipient(s). If you believe that you
have received this communication in error, please notify the sender immediately
by return e-mail and promptly delete this e-mail, including attachments without
reading or saving them in any manner. The unauthorized use, dissemination,
distribution, or reproduction of this e-mail, including attachments, is
prohibited and may be unlawful. Thank you.
--- End Message ---
--- Begin Message ---
I'm thinking that it should read
$rs = $conn->execute($q);
$outval = odbc_columns($rs, "DB#LIBNAME", "%", "TABLENAME", "%");
You need to provide the results of the query to the odbc_columns, not the
connection object.
Just my guess since I've never used this.
--- End Message ---
--- Begin Message ---
Thanks for your response... I changed the $outval line to
$outval = odbc_columns($rs, "DB#LIBNAME", "%", "TABLENAME", "%");
...but still got the same error -
Warning: odbc_columns() expects parameter 1 to be resource, object given
in D:\WAMP\www\directory\filename.php on line 13
-----Original Message-----
From: Jim Giner [mailto:jim.gi...@albanyhandball.com]
Sent: Thursday, January 26, 2012 10:31 AM
To: php-gene...@lists.php.net
Subject: [PHP] Re: Getting Column Names from an AS400 Database
I'm thinking that it should read
$rs = $conn->execute($q);
$outval = odbc_columns($rs, "DB#LIBNAME", "%", "TABLENAME", "%");
You need to provide the results of the query to the odbc_columns, not
the
connection object.
Just my guess since I've never used this.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Notice: This communication, including attachments, may contain information that
is confidential and protected. It constitutes non-public information intended
to be conveyed only to the designated recipient(s). If you believe that you
have received this communication in error, please notify the sender immediately
by return e-mail and promptly delete this e-mail, including attachments without
reading or saving them in any manner. The unauthorized use, dissemination,
distribution, or reproduction of this e-mail, including attachments, is
prohibited and may be unlawful. Thank you.
--- End Message ---
--- Begin Message ---
On 26-01-2012 16:40, Cheryl Sullivan wrote:
Thanks for your response... I changed the $outval line to
$outval = odbc_columns($rs, "DB#LIBNAME", "%", "TABLENAME", "%");
...but still got the same error -
Warning: odbc_columns() expects parameter 1 to be resource, object given
in D:\WAMP\www\directory\filename.php on line 13
-----Original Message-----
From: Jim Giner [mailto:jim.gi...@albanyhandball.com]
Sent: Thursday, January 26, 2012 10:31 AM
To: php-gene...@lists.php.net
Subject: [PHP] Re: Getting Column Names from an AS400 Database
I'm thinking that it should read
$rs = $conn->execute($q);
$outval = odbc_columns($rs, "DB#LIBNAME", "%", "TABLENAME", "%");
You need to provide the results of the query to the odbc_columns, not
the
connection object.
Just my guess since I've never used this.
According to the manual, the connection resource should be used.
But anyway, that's not the problem.
The problem is that you're starting with a COM Object, and all of a
sudden try to use the odbc functions on it. Of course that blows up in
your face, since COM !== ODBC.
Instead, you should use the properties and methods from the COM OLE
Object you've instantiated. I don't know what these are exactly, but I'm
sure you'll be able to find them in the MSDN reference somewhere.
Just remember that using the COM API will make things a lot harder for
you, since you can't rely on the PHP Manual to help you with anything.
If you're familair with the OLE object you're using, it shouldn't post
any problems though.
- Tul
--- End Message ---
--- Begin Message ---
On 26-01-2012 16:40, Cheryl Sullivan wrote:
Thanks for your response... I changed the $outval line to
$outval = odbc_columns($rs, "DB#LIBNAME", "%", "TABLENAME", "%");
...but still got the same error -
Warning: odbc_columns() expects parameter 1 to be resource, object given
in D:\WAMP\www\directory\filename.php on line 13
-----Original Message-----
From: Jim Giner [mailto:jim.gi...@albanyhandball.com]
Sent: Thursday, January 26, 2012 10:31 AM
To: php-gene...@lists.php.net
Subject: [PHP] Re: Getting Column Names from an AS400 Database
I'm thinking that it should read
$rs = $conn->execute($q);
$outval = odbc_columns($rs, "DB#LIBNAME", "%", "TABLENAME", "%");
You need to provide the results of the query to the odbc_columns, not
the
connection object.
Just my guess since I've never used this.
According to the manual, the connection resource should be used.
But anyway, that's not the problem.
The problem is that you're starting with a COM Object, and all of a
sudden try to use the odbc functions on it. Of course that blows up in
your face, since COM !== ODBC.
Instead, you should use the properties and methods from the COM OLE
Object you've instantiated. I don't know what these are exactly, but I'm
sure you'll be able to find them in the MSDN reference somewhere.
Just remember that using the COM API will make things a lot harder for
you, since you can't rely on the PHP Manual to help you with anything.
If you're familair with the OLE object you're using, it shouldn't post
any problems though.
- Tul
--- End Message ---
--- Begin Message ---
Cheryl:
In the PHP Manual ;
resource odbc_columns ( resource $connection_id [, string $qualifier [,
string $schema [, string $table_name [, string $column_name ]]]] )
Lists all columns in the requested range.
Parameters
connection_id The ODBC connection identifier, see odbc_connect() for
details.
qualifier The qualifier.
schema The owner.
table_name The table name.
column_name The column name.
I the first email you send: $outval = odbc_columns($conn, "DB#LIBNAME", "%",
"TABLENAME", "%");
$conn is truly a connection object ?
You check if has no errors in the connection processes?
Alejandro M.S.
-----Mensagem original-----
De: Cheryl Sullivan [mailto:csull...@shh.org]
Enviada em: quinta-feira, 26 de janeiro de 2012 13:41
Para: Jim Giner; php-gene...@lists.php.net
Assunto: RE: [PHP] Re: Getting Column Names from an AS400 Database
Thanks for your response... I changed the $outval line to
$outval = odbc_columns($rs, "DB#LIBNAME", "%", "TABLENAME", "%");
...but still got the same error -
Warning: odbc_columns() expects parameter 1 to be resource, object given in
D:\WAMP\www\directory\filename.php on line 13
-----Original Message-----
From: Jim Giner [mailto:jim.gi...@albanyhandball.com]
Sent: Thursday, January 26, 2012 10:31 AM
To: php-gene...@lists.php.net
Subject: [PHP] Re: Getting Column Names from an AS400 Database
I'm thinking that it should read
$rs = $conn->execute($q);
$outval = odbc_columns($rs, "DB#LIBNAME", "%", "TABLENAME", "%");
You need to provide the results of the query to the odbc_columns, not the
connection object.
Just my guess since I've never used this.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Notice: This communication, including attachments, may contain information
that is confidential and protected. It constitutes non-public information
intended to be conveyed only to the designated recipient(s). If you believe
that you have received this communication in error, please notify the sender
immediately by return e-mail and promptly delete this e-mail, including
attachments without reading or saving them in any manner. The unauthorized
use, dissemination, distribution, or reproduction of this e-mail, including
attachments, is prohibited and may be unlawful. Thank you.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On 26 Jan 2012, at 14:44, Floyd Resler wrote:
> I am using __autoload for my site which is conflicting with the autoloading
> of PHPExcel. I tried using spl_autoload_register thinking that might be the
> way to go but when I tried I got a "cannot be redeclared" error. I include
> my autoload script (include_once "../../lib/autoload.php";) and my
> autoload.php script looks like this:
> <?
> function __autoload($class_name) {
> $path="../../lib/class.$class_name.php";
> if(file_exists($path)) {
> require_once $path;
> }
> }
> ?>
>
> As stated, when I change __autoload to spl_autoload_register I get the can't
> be redeclared error. Any ideas?
spl_autoload_register is a function you call, not a function you define. See
the example on the manual page for that function.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On Jan 26, 2012, at 10:15 AM, Stuart Dallas wrote:
> On 26 Jan 2012, at 14:44, Floyd Resler wrote:
>
>> I am using __autoload for my site which is conflicting with the autoloading
>> of PHPExcel. I tried using spl_autoload_register thinking that might be the
>> way to go but when I tried I got a "cannot be redeclared" error. I include
>> my autoload script (include_once "../../lib/autoload.php";) and my
>> autoload.php script looks like this:
>> <?
>> function __autoload($class_name) {
>> $path="../../lib/class.$class_name.php";
>> if(file_exists($path)) {
>> require_once $path;
>> }
>> }
>> ?>
>>
>> As stated, when I change __autoload to spl_autoload_register I get the can't
>> be redeclared error. Any ideas?
>
> spl_autoload_register is a function you call, not a function you define. See
> the example on the manual page for that function.
>
> -Stuart
>
Yeah, silly me for not reading the manual page! :) It's amazing how well it
works when you follow the instructions!
Thanks!
Floyd
--- End Message ---
--- Begin Message ---
On Jan 11, 2012, at 9:24 PM, tamouse mailing lists wrote:
> Is there ever a case where SCRIPT_NAME does not equal PHP_SELF?
Was this every answered? I would like to know.
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
