Many thanks for your detailed description. If save me a lot of time.

At 16:35 03/10/10 +0200, you wrote:

>Almond wrote:
> > I do some experiment. The code to read and re-submit is ok. So, I think it
> > is not difficult to write the remaining code. Now I want to know is :
> >
> > 1. How many record have you post back in one batch. Is that 200+ record
> > would cause problem ? I think the size should not exceed 50K. Any problem
> > if the connection speed is slow (<10K) ?
>
>Depends on how much your webserver can handle :). Check php.ini to see
>how much memory can a single script consume. I use Apache 1.3 with PHP
>4.3, IIRC the default was 8MB, and I haven't had any problems with that
>so far. You can always limit the number of rows on screen and force
>users to click "Next >>" and "<< Prev" buttons or whatever. If they are
>really searchin for something, provide the search for them. Noone likes
>to browse table with 1000 rows just to find the one (s)he needs.

"Next >>" and "<< Prev" is difficult for a lazy man ;). The grid is used
only for child tables which is not exceed 200 row. Most of them is text and
no search required.

>As for the speed, there are two issues. First is the amount of data
>(html) sent to the browser. You can test it yourself, everything below
>100kB is acceptable (for me). Other issue is updateing/inserting into
>database. Be sure to use prepared statements and just fill parameter
>values and execute. If you're about to edit the entire tables, you can
>make one hidden field which shows wheter any field in that row is
>changed, so you don't have to update rows which are left intact. It can
>be all automated with javascript, but be very careful about it. JS
>doesn't handle fields with [ and ] in name very well, so you'll have to
>think of some other way of accessing it. I use searchig for substring in
>input element's name. If you have a lot of controls it can be somewhat
>slow on some older machines (like Pentinum I or similar). But there are
>some ways to reduce the number of searches... but that's a topic for itself.
>
>There is alternative way to name your input fields numerically or
>somewhat similar (field00010003, field00010002) which mark rows and
>columns, which gives you almost instant JS, but you would have an extra
>job when the form is posted... you'd have to parse all input variables
>and turn them into appropriate php array or whatever you like. Php's
>variable variable names (the thing with $$var_name) come very handy for
>that.

Yes, it is what I did in the testing code. I found some sample use array,
but I cannot get if work. Is there is no difference using on $_REQUEST or
$_POST to get the data ?

> > 2. Any comments on that kind of code ? Is that post back so many variables
> > (2,000+) would cause problem, ?
>
>It shouldn't. It works for me (TM), but you can easily test yourself. I
>find PHP to be very robust and capable of handling any amount of data.
>
>I suggest you to do this only when it's really needed. Web applications
>are made to be web applications, and trying to make something other of
>it can result in very complex and hard to understand code.
>

Thank you for your reply and comment. Have a nice weekend.

Best regards,

Almond Wong

>--
>Milan Babuskov
><http://fbexport.sourceforge.net>http://fbexport.sourceforge.net
>
>
>
>Yahoo! Groups Sponsor
>ADVERTISEMENT
><http://rd.yahoo.com/M=251812.4024216.5238180.1261774/D=egroupweb/S=1705007183:HM/A=1754452/R=0/SIG=11tadqrng/*http://www.netflix.com/Default?mqso=60178324&partid=4024216>1463fc71.jpg
>1463fcf3.jpg
>
>To unsubscribe from this group, send an email to:
>firebird-php-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to the
><http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.

[Non-text portions of this message have been removed]