Good Morning...

I am running into an issue trying to run a table rebuilding script that I wrote, and I'm wondering if it is due to including a script that also includes itself multiple times, depending upon the results generated by the script itself...

That may sound a bit confusing, but here is what it does...

I have a script that I INCLUDE called pos_create which basically uses the available data to create a position in a matrix
The creation of that position may cause another position in the matrix to cycle, which would generate another reentry position, and I basically just add that position id to a DBtable (Stack) for later processing...
The included script continues processing, doing multiple processes until complete...

Then, at the end of the included script, I check query the (Stack) table for any unprocessed records, and if there are any, I assign the necessary variables and INCLUDE the same script that is currently running again to go through the same process...

Trying to rebuild multiple tables from a single Transaction table that has 3700 +- transactions in it. The script works fine through about 1200 then stops, and when I try to rerun it from that point, it gets 20 +- more and stops again... then after doing this 3-4 times it gets 1-2 records processed on each restart.

Can someone explain why this would be? It is taxing local resources? Is there just an inherent problem with including a script from itself? I'm perplexed, and this has been driving me nuts for a few days now.

thanks in advance for any enlightenment you may have to offer.


Edited by showman13: clarification of question

4 Years
Discussion Span
Last Post by showman13

It is taxing local resources?


Here's a simple example:


echo "Hello World!";


$count = 0;

$start = memory_get_peak_usage();
    include 'inc.php';
$end = memory_get_peak_usage();

echo "<br />".$start."::".$end;


$count = 0;

$start = memory_get_peak_usage();
    echo  "Hello World!";
$end = memory_get_peak_usage();

echo "<br />".$start."::".$end;

Run the includePerfCheck.php and simpleRunCheck.php.
I hope it clearly tells how bad-a$$ including a lot of script is. :D
Anyway, just a question how many includes are we talking about, with your script?
If possible can you show us your script?

Edited by gon1387


An additional though, check you script execution time, and set it somewhere you think would be possible for the script to finish its execution.

Edited by gon1387


That particular INCLUDE is 384 lines long, so don't really think I need to post it in here...

basically when a purchase is made from the main script, it does the
INCLUDE "pos_create.php"
which just sets a couple of control variables,
Then Calls a Function that actually creates the position (150 lines long)
which returns the position ID that was created..
Then it does a bunch of processing and recording of payments that are made in various tables
And sends out an email to the owner of the new position
Then Calls a Function that Checks to see if that position placement based on position number has caused a cycle.

If a cycle was created, it returns the position id that cycled
The position id and other relevant information is written to the pos_earned table:
And more processing takes place updating other tables and sending out another email for cycle notification...
Which basically ends the processing...

Then it queries the pos_earned table to see if there are any unprocessed records, and if it finds one, it marks it as being processed and gathers the data, then
it does the INCLUDE "pos_create.php" again

Which would go through the entire process each time then check for any additional cycles, etc... Until it runs out, and returns execution to the main script.

Not sure all this will help, but it is the process.

BTW, I ran those little test scripts and it does point out a major difference in the time cost in using includes.

I'm wondering if there is a better struture to use than what I am doing...
I'm sure someone will say OOP, and that may be true, but I have no idea where to start with that and just imagine the learning curve on that wouldn't be short, but my time for finding a resolution is.

thanks for any feedback you may have


Eventhough we have our own preference in programming, the style or language we use, it's better to explore all/some options, for us to know what's best on a partic stituation. What I mean is it's better for us to spend time to explore different avenues of learning and commiting mistakes, so for us to save time in the future; than staying or sticking into what we know and commiting the same mistakes without any other options of selecting a better solution for a particular situation. To cut it short, spend time to save time. :D

Anyway, I almost thought your script was a background work though, with all the number of stuffs running. If you want it modular, why not make the pos_create modular in a way you create a funtion out of it. Then, just call the function instead of including the same file all over. In that way, you save resources for including the file multiple time.

include 'pos_funcs.php'; \\Where your pos_create() is

    pos_create(..some arguments...);

Edited by gon1387


You know... it seems I thought about doing it as a function at one point in time but for some reason decided not to. Can't tell you what that reason was though.

That might actually be a sensible solution, but need to re-evaluate that option to see if there would be anything standing in the way of doing it...

Would definitely eliminate a lot of includes.

Thanks for the suggestion (memory jogger)

Think I will try that and if I can't work it out, then I can revisit this question..



Sure, it's nothing.
Let me know if you you have it solved or stuck in a problem. I'll just standby here.


OK, so, I'm working on converting to functions as opposed to includes... Will let you know how that goes

But in the process, I decided that I need to figure out how to capture a record that needs to be updated, and at the same time prevent any other process from grabbing the same record and trying to update it. Hope that makes sense

What I'm looking for is a way to do an UPDATE of a table record based on the status='E', LIMIT 1 and then get the rec_id of the record that was updated if one existed, or get nothing if there weren't any records with a status of 'E'...

Basically what I need to do is to know if any re-entry or upgrade positions need to be created, by checking in the pos_create table, because while the original position is being created, if it causes a cycle, it will cause both a reentry and an upgrade 'Earned' record to be written to the pos_earned table.

I guess the only real question in all that is if there is a way to do it in a single query?
OR if I need to do the update first

            UPDATE pos_earned
            SET status='T'
            WHERE status='E'
            AND from_sequence='".$prev_loc."'
            AND from_pos='".$prev_pos."'

AND then
Do a second query to retrieve the affected ent_id(if there was a record to update)

//#####  Query earned position table for record with status of 'T' limit 1
    // update status to Placed then do necessary processing
  $sql_r="SELECT ent_id, mem_id, from_sequence, from_pos, to_sequence, create_date, pos_type, follow_id
    FROM pos_earned
    WHERE status='T'
    AND from_sequence='".$prev_loc."'
    AND from_pos='".$prev_pos."'
    LIMIT 1
    $sql_ur = "
        UPDATE pos_earned
        SET status='P', last_update='".$created."'
        WHERE ent_id = '".$row_r[0]."'
    // set variables
    $mk_pos=$row_r[4];  // re-entry to same sequence or upgrade to next
    $type=$row_r[6];// re-entry/upgrade remains what cycling position was
    $under=$row_r[7]; // originated from members record

   // drop out and do something else

I hope all of that made sense... and hopefully there is a way to do it all in one query, but I'm guessing that won't be the case.

thanks in advance


This question has already been answered. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.