php-general Digest 27 Jan 2007 18:24:58 -0000 Issue 4593
Topics (messages 247873 through 247891):
connect.c+php
247873 by: ed gregory
cennect.c+php
247874 by: Eduard Grigoryan
Re: SQL Readability.. (was Re: most powerful php editor)
247875 by: Satyam
247877 by: Jochem Maas
247887 by: Robert Cummings
247888 by: Larry Garfield
Rory Browne from this php list (0.T)
247876 by: Ryan A
Re: PHP & Flash
247878 by: Jochem Maas
Re: Create ACH Origination file with PHP
247879 by: Jochem Maas
247885 by: Jay Blanchard
Re: Result sorting not working
247880 by: Jochem Maas
Re: php & javascript interaction
247881 by: Jochem Maas
navigation
247882 by: koen
247883 by: Jay Blanchard
247886 by: Myron Turner
Re: Can a class instance a property of another class
247884 by: Edward Kay
247889 by: Jochem Maas
247890 by: Ken Kixmoeller -- reply to ken.kixmoeller.com
Sporadic MSSQL connection error
247891 by: kentozier.comcast.net
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
php-general@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Can anyone give me an example on using connect.c with php?
Thank you.
Ed
--
http://www.freenet.am/
--- End Message ---
--- Begin Message ---
Can anyone give me an example on using connect.c with php?
Thank you.
Ed
--
********************************
Armenian Freenet Catalog
http://freenet.am/~edik_g
http://armfn.net/~edik_g
********************************
--- End Message ---
--- Begin Message ---
----- Original Message -----
From: "Larry Garfield" <[EMAIL PROTECTED]>
To: <php-general@lists.php.net>
Sent: Saturday, January 27, 2007 12:18 AM
Subject: Re: [PHP] SQL Readability.. (was Re: most powerful php editor)
I have long since given up on raw insert/update/delete statements as the
syntax is all kinds nasty. These days I just do this, which is even
easier
and more powerful:
http://www.garfieldtech.com/blog/simplifying-sql
I tried the following:
insert('sometable',array('when' => mktime(0,0,0,2,1,2007),'if' => true));
which produced the following SQL statement:
INSERT INTO sometable (when) VALUES (1170284400,1170284400)
The problem is that PHP types do not correspond to SQL types. Though a
boolean does identify itself as such, a date never does. Your switch() on
the gettype() of the value misses the type 'boolean' so it falls through the
default: case which then appends whatever was left from the previous pass.
However, even adding a case for type boolean there is no way to recognize
dates since they are no more than integers for all PHP cares. Finally, what
happens with an expression that produces a sort-of boolean, like anything
non-zero for true?
Those are the reasons I used type modifiers in my BuildSql function
(http://www.satyam.com.ar/int/BuildSql.php), I couldn't rely on PHP figuring
them out correctly. This also allowed me to expand those modifiers to
optional positional modifiers and null handling ones.
I even tried to query the SQL engine to report them back, but that was also
unreliable, MySql for one, reports the type of what it used to store it, not
what you declared them to be. Thus, for a boolean field it will report
integer, but if you try to store a number other than 0 or 1 it then
complains. So, unable to get reliable information from either end, I
decided on stating the type explicitly on the query string.
Satyam
On Friday 26 January 2007 10:03 am, [EMAIL PROTECTED] wrote:
My contribution to the insanity.. INSERT statements made easy:
$genericQY = "INSERT INTO MOD_LMGR_Leads ("; $genericQYvalues = "
VALUES
("; $genericQY .= " FirstName,"; $genericQYvalues .= "
'John',"; $genericQY .= " LastName"; $genericQYvalues
.= " 'Smith'"; $genericQY .= " )";
$genericQYvalues .= " );"; $genericQY .= $genericQYvalues;
$genericRS = mysql_query($genericQY);
I use this structure so if I decide that I don't need certain data I can
comment out a single line to remove the column name and corresponding
value. Also helpful for making updates to column/value pairs and not
worry
about the dreaded error involve # of columns not matching.
Only things you have to watch for:
1. Make sure you don't have a comma on the last item
2. Make sure you have spaces where appropriate so when it concatenates
the
strings, you don't get stuff crammed together (not really an issue with
the
INSERT statement, but I try to keep a consistant practice with all my
queries so I don't slip up.. SELECT columnsFROM tableWHERE something =
something is where it really gets ya if you forget spaces.. just as an
example) 3. Make sure to remember to concatenate the "query" and "values"
parts
I like to think this is a little "outside the box" thinking since common
practice is "one command, one line" or "total chaos" hah.
Any comments on improving this or other unique stylistic ways people like
to design their code?
-TG
= = = Original message = = =
On Wed, January 24, 2007 8:07 pm, Robert Cummings wrote:
> On Wed, 2007-01-24 at 18:23 -0600, Richard Lynch wrote:
>> On Wed, January 24, 2007 7:41 am, Roman Neuhauser wrote:
>> > # [EMAIL PROTECTED] / 2007-01-24 13:57:03 +0200:
>> >> and also in these days I'm looking for 19 inch (or more) wide LCD
>> >> sceerns to able to fit longer lines in my screen...
>> >
>> > Number of reading errors people make grows with line length,
>> > this has been known for as long as I remember. You're increasing
>>
>> the
>>
>> > probability of bugs in the code, and get tired sooner because
>> > following
>> > long lines requires more energy.
>>
>> I believe those results are specific to what is being read.
>>
>> Surely it's easier to read:
>>
>> SELECT blah, blah, blah, blah, blah, blah, blah, blah, blah
>>
>> if it's all on one line, no matter how many fields there are, while
>> trying to read the code as a whole.
>>
>> Sure, it can be "hard" to find/read the individual field names, on
>> the
>> rare occasion that you need to do that...
>
> Dear Mr Lynch, normally I highly respect your commentary on the list,
> but today I think you've been-a-smoking the crackpipe a tad too much.
>
> There is no way in hell one long line of SQL is easier to read than
> formatted SQL that clearly delineates the clause structure.
>
> SELECT A.field1 AS afield1, A.field2 AS afield2, B.field1 AS bfield1,
> B.field2 AS bfield2, C.field1 AS cfield1, C.field2 AS cfield2,
> D.field1
> AS dfield1, D.field2 AS dfield2 FROM tableA as A LEFT JOIN tableB AS B
> ON B.fee = A.foo LEFT JOIN tableC AS C ON C.fii = B.fee LEFT JOIN
> tableD
> AS D ON D.fuu = C.fii WHERE A.foo = 'someValue' ORDER BY afield1 ASC,
> cfield2 ASC
>
> The above line "should" be on one line, but my email client might
> autowrap it. Either way, the following is formatted and is much
> clearer.
>
> SELECT
> A.field1 AS afield1,
> A.field2 AS afield2,
> B.field1 AS bfield1,
> B.field2 AS bfield2,
> C.field1 AS cfield1,
> C.field2 AS cfield2,
> D.field1 AS dfield1,
> D.field2 AS dfield2
> FROM
> tableA as A
> LEFT JOIN tableB AS B ON
> B.fee = A.foo
> LEFT JOIN tableC AS C ON
> C.fii = B.fee
> LEFT JOIN tableD AS D ON
> D.fuu = C.fii
> WHERE
> A.foo = 'someValue'
> ORDER BY
> afield1 ASC,
> cfield2 ASC
>
>
> While the above is contrived, most of us know such examples happen
> quite
> often in the wild. Not only is it easier to read, but the task of
> adding
> or removing selected fields is trivial.
I meant ONLY the SELECT part on a single line.
Only a moron would cram the FROM and all that into the same line.
:-)
$query = "SELECT blah1, blah2, blah3, ... blah147 ";
$query .= " FROM table1 ";
$query .= " LEFT OUTER JOIN table2 ";
$query .= " ON blah7 = blah42 ";
$query .= " WHERE blah16 ";
$query .= " AND blah42 ";
$query .= " ORDER BY blah9, blah8 desc, blah6 ";
is what I go for.
The SELECT line is the only one that ever gets all that long, really...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the
possession
of every one, and the receiver cannot dispossess himself of it." --
Thomas
Jefferson
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Larry Garfield wrote:
> I have long since given up on raw insert/update/delete statements as the
> syntax is all kinds nasty. These days I just do this, which is even easier
> and more powerful:
>
> http://www.garfieldtech.com/blog/simplifying-sql
>
a quick look at those funcs gives me the impression that they are woefully
inadequate for any level of complex realworld use.
query builders are alot more fiddly to get 'right' than one might imagine,
dealing with NULLs, booleans and dates for example (as Satyam pointed out)
can be a right PITA.
perfect automated CRUD (it's an acronym!) is kind a holy grail - and
that is, I think, the driving force behind most attempts to crteate query
builders.
also I don't really agree with the sentiment that SQL syntax is nasty,
personally I find it, mostly, very easy to read and powerful ... but as this
thread shows there is no accounting for taste! :-)
--- End Message ---
--- Begin Message ---
On Sat, 2007-01-27 at 14:43 +0100, Jochem Maas wrote:
>
> also I don't really agree with the sentiment that SQL syntax is nasty,
Hear, hear :)
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
On Saturday 27 January 2007 7:43 am, Jochem Maas wrote:
> Larry Garfield wrote:
> > I have long since given up on raw insert/update/delete statements as the
> > syntax is all kinds nasty. These days I just do this, which is even
> > easier and more powerful:
> >
> > http://www.garfieldtech.com/blog/simplifying-sql
>
> a quick look at those funcs gives me the impression that they are woefully
> inadequate for any level of complex realworld use.
That's interesting, because I've been using variants of that for a year now
with much success in a dozen projects.
> query builders are alot more fiddly to get 'right' than one might imagine,
> dealing with NULLs, booleans and dates for example (as Satyam pointed out)
> can be a right PITA.
I actually almost never use native date types in the SQL database. I just
store unix timestamps and do the math in PHP. Dates are completely
unportable anyway. I also tend to use ints for booleans, too, although
beefing up the switch statements in the code to handle native booleans should
be trivial.
> perfect automated CRUD (it's an acronym!) is kind a holy grail - and
> that is, I think, the driving force behind most attempts to crteate query
> builders.
Orthogonal persistence is, yes. The goal here was simply to make dealing with
arbitrary insert and update statements easier, which in practice I've found
to be a huge success. Full arbitrary CRUD and orthogonal persistence is much
harder. That's why there's a dozen ORMs out there, all of which have some
major flaw. :-)
> also I don't really agree with the sentiment that SQL syntax is nasty,
> personally I find it, mostly, very easy to read and powerful ... but as
> this thread shows there is no accounting for taste! :-)
What bugs me most about SQL syntax is INSERT vs. UPDATE. I don't know the
underlying implementation details of the engine, but from the level I work at
(sending SQL to a database from a web app) I see no legitimate reason why
those two very-similar statements should have ridiculously different syntax.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--- End Message ---
--- Begin Message ---
Hello!
As some of you might remember: a little while back I had a project to be done
in PHP, which I asked if anyone on the list would be interested in completing
for $800 USD.
Rory Browne from the list got the job and around the 15th of Jan he told me he
completed the work and was going to send me/setup the software but then I did
not get any word from him after multiple emails in the days since, am wondering
if something bad happened to him... (hope not)
Does anyone know Rory Browne's phone number or any other contact details?
Thanks,
Ryan
------
- The faulty interface lies between the chair and the keyboard.
- Creativity is great, but plagiarism is faster!
- Smile, everyone loves a moron. :-)
---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta.
--- End Message ---
--- Begin Message ---
Skip Evans wrote:
> Jochem Maas wrote:
>>> Anyone have any experience with PHP/Actionscript on Linux?
>>
>>
>> wtf?
ah ok, so the idiots guide to flash/php interaction wasn't really needed :-)
>
> Oh my God. What am I thinking? Please folks, I am really not this
> stupid. It has been too, too long a day. Yes, I just need to upgrade
> Flash on this workstation.
>
glad you got it sorted.
> Skip
--- End Message ---
--- Begin Message ---
Dan Harrington wrote:
> Hello,
>
> Does anyone know of a script that can create an ACH origination file
> with PHP?
SingTFW didn't turn up anything for php but maybe the following perl module
might help you to write the equivelant in php:
http://search.cpan.org/~tkeefer/ACH-Builder-0.02/lib/ACH/Builder.pm
>
> Thanks
> Dan
>
--- End Message ---
--- Begin Message ---
[snip]
Does anyone know of a script that can create an ACH origination file
with
PHP?[/snip]
How do you want to input amounts, routing numbers, and account numbers?
Have you checked out the NACHA file specifications? http://www.nacha.org
Do you need to perform file encryption before you transmit? How will you
transmit (FTP, SFTP, web service)? This is a simple question with many
variables.
Essentially the ACH file is a text file that is reasonably easy to
create with PHP and you can use either a database or file I/O or XML to
input amounts, routing, etc.
--- End Message ---
--- Begin Message ---
Dan Shirah wrote:
> I have a search page that displays all active records in my application,
> but
> for some reason, I can not get it to display based on a specific input.
>
> For instance, I have records with id's 2, 3, 4, 5 etc... In my search
> form,
> the default view shows all records, and my form variable lets you put in
> different search criteria. If I do a search by id and put in "2" as the
> search condition, my results keep coming back blank. It does not matter
> which parameter or value I put in, it still returns blank.
>
> Any ideas?
you don't bother to read your own code thoroughly? see below:
>
> <?php
> $connection = mssql_connect($host, $user, $pass) or die ('server connection
> failed');
> $database = mssql_select_db("$database", $connection) or die ('DB
> selection failed');
>
>
> // Query the table and load all of the records into an array.
> $query = "SELECT
> child_support_payment_request.credit_card_id,
> credit_card_payment_request.credit_card_id,
> credit_card_payment_request.date_request_received
> FROM child_support_payment_request,
> credit_card_payment_request
> WHERE child_support_payment_request.credit_card_id =
> credit_card_payment_request.credit_card_id";
> if ($request_id !== '') {
> $query.=" AND credit_card_payment_request.credit_card_id =
> $request_id2";
$request_id AND $request_id2 ??
> }
> if ($dateTime !== '') {
> $query.=" AND credit_card_payment_request.date_request_received =
> $dateTime2";
$dateTime AND $dateTime2 ??
...
ecified in a seperate
> chunk of
> php code, but are still included on the same page as the code below. Am I
> right in assuming that any variable set on the same page can be carried
> into
> different php blocks on the same page?
>
> Example:
>
> <?php
>
> $id = $_POST['request_id']
>
> ?>
>
> <?php
>
> echo "<table>";
> echo "<td>"'
> echo $id;
> echo "</td>";
> echo "</table>";
>
> ?>
>
> That would be valid, correct?
yes.
>
--- End Message ---
--- Begin Message ---
William Stokes wrote:
> Hello,
>
> I need some advice on how to learn Javascript and PHP interaction. Any good
> tutorials on the web would be most welcome. I particulary need to learn how
> to pass JS user input/choices to PHP.
>
> My current problem is how to ask user confirmation over his actions on a web
> form after POST. "Are you sure" type questions and how to pass the user
> choice back to program make choices with PHP.
http://php.net/json
http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html
^^-- note the name! toys.lerdorf.com is a veritable goldmine of
funky info, lots of php magic to be had there.
>
> Thanks
> -Will
>
--- End Message ---
--- Begin Message ---
How to creat the effect of the explorers back and forward buttons in php?
--- End Message ---
--- Begin Message ---
[snip]
How to creat the effect of the explorers back and forward buttons in
php?
[/snip]
Since PHP is server side you would have to use Javascript to do this.
See
http://www.comptechdoc.org/independent/web/cgi/javamanual/javahistory.ht
ml
--- End Message ---
--- Begin Message ---
koen wrote:
How to creat the effect of the explorers back and forward buttons in php?
It's a javascript issue, using the javascript history object.
--
_____________________
Myron Turner
http://www.room535.org
http://www.bstatzero.org
http://www.mturner.org/XML_PullParser/
--- End Message ---
--- Begin Message ---
Hey - -- -
Here I am again. Anybody still working on a Friday?
I would like to have a class instance be the property of another
class, like can be done in other languages. For example: I would like
to have a "Connections" class which contains all of the database
connection logic and query results. There are advantages to having
this type of utility class be local to a data or business class. (I
know that I could have a generic "include" with functions outside of
the class hierarchy.)
So, in the __construct method of a business or data class, for
example, one could:
include_once("connection_classes.kbk");
$this->connection_class = new connection_class;
This syntax fails, so I know this isn't right, but I hope you get the
idea.
This fails simply because you've omitted the parentheses on the
constructor. It should be:
$this->connection_class = new connection_class();
Of course, you may want/need to pass some arguments here too.
As mentioned by others though, for the scenario you describe above, you
would probably be better extending a base class.
Edward
Can it be done?
TIA, again
Ken
--PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Edward Kay wrote:
>
>> Hey - -- -
>>
>> Here I am again. Anybody still working on a Friday?
>>
>> I would like to have a class instance be the property of another
>> class, like can be done in other languages. For example: I would like
>> to have a "Connections" class which contains all of the database
>> connection logic and query results. There are advantages to having
>> this type of utility class be local to a data or business class. (I
>> know that I could have a generic "include" with functions outside of
>> the class hierarchy.)
>>
>> So, in the __construct method of a business or data class, for
>> example, one could:
>>
>> include_once("connection_classes.kbk");
>> $this->connection_class = new connection_class;
>>
>> This syntax fails, so I know this isn't right, but I hope you get the
>> idea.
> This fails simply because you've omitted the parentheses on the
> constructor. It should be:
>
> $this->connection_class = new connection_class();
WRONG - the parentheses are optional - my example in a a previous reply
to this thread proves this (if you care to test it).
>
> Of course, you may want/need to pass some arguments here too.
>
> As mentioned by others though, for the scenario you describe above, you
> would probably be better extending a base class.
I see no real justification for class extension at this stage, it *may* be the
best
way to tackle this situation BUT there may be good reasons that the class in
question
lives in it's own seperate class heirarchy.
object aggregation is just as valid as class extending in principle.
--- End Message ---
--- Begin Message ---
Thanks for your help, guys. I had to leave my office last evening
before I had a chance to try any of them.
I am sneaking in some office time today. I'll let you know (with
complete scripts and error messages).
Ken
--- End Message ---
--- Begin Message ---
Hi
I'm having a sporadic connection problem with MSSQL. I have a php script which
is called by a folder scanning application and sometimes it can run for hours
without problem but other times it will run for just a few minutes and return
connection errors. I tried using mssql_get_last_message but it always seems to
return an empty string.
I'd like to find out why the connection is failing but in the absense of error
info from MSSQL, it's a bit problematic. Is there a creative way to actually
get error strings back from MSSQL in light of the fact that
mssql_get_last_message basically does squat?
As a last ditch effort, I could run the connect line in a loop a set number of
times until it succeeds but I would prefer to know why it fails.
Can anyone offer suggestions?
Thanks
Ken
--- End Message ---
