NYCPHP Meetup

[Marc Antony Vose]

Hey guys:

I don't think I was clear enough in my original email: I know what 
the problem is.  phpMyAdmin isn't spitting out INSERT statements that 
MySQL accepts.  It is spitting out this:

INSERT INTO `cat_49` (`cat_49_id`, `cat_49_content_area`, 
`cat_49_parent`, `cat_49_name`, `cat_49_description`, 
`cat_49_sort_num`, `cat_49_active`, `cat_49_added`, `cat_49_updated`) 
VALUES (1, 49, 0, 0x414652494341, '', 0, 'y', '2004-01-05 09:34:22', 
2004-01-06 13:03:44);

Notice that the last field, a timestamp field, is not quoted.

Even if I just paste ONE of these INSERTs into phpMyAdmin on the 
other side, it fails.  If I quote the timestamp value, it works.

I have all the options I can find set to quote things.  I even looked 
through the config file.

Isn't this a bug?

I guess my only option is to just grep search and replace, or wade 
through the phpMyAdmin source and change how it dumps timestamp 
fields.  I am dealing with the latest "stable" version of phpMyAdmin, 
which I downloaded and installed today.  It is 2.5.6.

Marc





>On Tue, 6 Apr 2004, Marc Antony Vose wrote:
>
>>  Thing is, phpMyAdmin is dumping things in a format that it itself 
>>cannot read!
>
>>From what I've heard, (I don't use the program) phpMyAdmin has it's
>own MySQL parser because you can't dump multiple SQL statements to
>MySQL using it's client API.
>
>This is fixed in PHP 5/MySQL 4.1/mysqli, so eventually this problem
>will go away. In the meantime, I would try feeding in chunks
>bit-by-bit, seeing where the SQL causes a barf, and looking if there's
>something obvious you can fix.
>
>-adam
>
>--
>adam at trachtenberg.com
>author of o'reilly's php cookbook
>avoid the holiday rush, buy your copy today!
>_______________________________________________
>talk mailing list
>talk at lists.nyphp.org
>http://lists.nyphp.org/mailman/listinfo/talk


>From hans not junk at nyphp.com  Tue Apr  6 16:11:28 2004
Return-Path: <hans not junk at nyphp.com>
Received: from ehost011-1.exch011.intermedia.net (unknown [64.78.21.3])
	by virtu.nyphp.org (Postfix) with ESMTP id 1E7A4A85F7
	for <talk at lists.nyphp.org>; Tue,  6 Apr 2004 16:11:28 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nycphp-talk] phpAdsNew
Date: Tue, 6 Apr 2004 13:11:25 -0700
Message-ID: <41EE526EC2D3C74286415780D3BA9F87014278D3 at ehost011-1.exch011.intermedia.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [nycphp-talk] phpAdsNew
Thread-Index: AcQcEIKIOtOQT7YoS3mZT9b7L9y47wAAlpkw
From: "Hans Zaunere" <hans not junk at nyphp.com>
To: "NYPHP Talk" <talk at lists.nyphp.org>
X-BeenThere: talk at lists.nyphp.org
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: NYPHP Talk <talk at lists.nyphp.org>
List-Id: NYPHP Talk  <talk.lists.nyphp.org>
List-Unsubscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=unsubscribe>
List-Archive: <http://lists.nyphp.org/pipermail/talk>
List-Post: <mailto:talk at lists.nyphp.org>
List-Help: <mailto:talk-request at lists.nyphp.org?subject=help>
List-Subscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2004 20:11:28 -0000


> See, IMO, an ad server would have to save the impressions a row at a
> time because of how you want the information queried at the end of the
> day.

Absolutely... but there are different ways to slice it.

1) cache hits in memory, then batch load them into a DB so that you're
not having to hit the DB on every banner load

2) use MySQL's heap tables, then do a batch load

3) cache hits into a file, then batch load

Or some variation/combo thereof.

All that said, this wasn't our problem, and probably not a problem
except for those very highly trafficked sites there seem to be so many
of.

Our issue was the loading of the actual banner.  At the time we deployed
phpadsnew, the graphic itself was being streamed out of the database,
through php, and finally to the browser.  Again, this didn't end up
being a performance problem; however, the problem was that the banners
had a visible "fill" effect when the page loaded, and it caused a
noticeable delay for page loads.  This might have been something fixed
up in later versions of phpadsnew.

H