prob with tbsdb_ezsql.php for ezSQL v2.0 ?

Hi Skrol29,

Since the update for ezSQL 2.0 I have been reviewing old apps to insure all okay -- the only problem that has surfaced is with a
[var.header_file;script=insert_menu_ez2.php;subtpl] block...
under ezSQLv2 the "insert_menu.php" file no longer returns the data rows (no errors either) Working and broken examples can be seen <a href="http://tomhenry.us/tbs/eztbs_snippets/index.html">HERE</a> with all the source code.

Snippets for your review...
main.php

main.html

insert_menu.php

insert_menu.html

Reminder - this all works perfectly under TBS (no ezsql) and TBS+ezSQv1.26 !!

Any ideas on whether the new chenges
to tbsdb_ezsql.php for ezSQL v2 might have something to do with this
This is tha same app that you helped me with before (TBS and ezSQL v1.26) and your help was greatrly appreciated, thanks.

Any help / ideas appreciated,
[var.thanks.for.TBS]
Tom

Hello Tom,

Thank you for to giving such precision and effort to present your problem. I think I've got the solution.

In subscript "insert_menu_ez2.php" , when you code: Then I think the connection to your database is not done. Here is why:
The file "xxxx.inc" has already been included in the main script, so it won't this time. Then variables $db_user, $db_password, $db_name, $db_host are not set again. But in the context of sub-script, they are local variables, different from same named global variables.
Thus, those variables are empty. And connection fails. No connection, and no result.

Looking at your problem, I've discovered that ezSQL 2 has a bold way of displaying error messages. We have to use Php set_error_handler() function for that.
If you use this function, I guess you will have more information about ezSQL error messages.

Great. That change corrected to non-working ez2 scripts into working scripts... so I am really thankful to you for helping.

I am however very perplexed by this -- tha very same script(s) running under ezsql v1.26 did run just perfectly even though they too had "include_once()" code.  How is this something that is diff from ezv1 to ezv2?   I don't understand that part of why this fixed the problem. DO you see what I mean?


And another thing -- (maybe caused by the same issue) -- the 'same named' vars in the second script will contain the vals from the main script all the time.  If they were 'local' vars then I would expect the vals to be rendered in the second  template to have the local vals - but that is not the case.  Ideas?

Thanks a lot for helping,

Tom [var.thanks.for.TBS]

Some testing on what said prev...

I placed a var in Mian file and same var in SUb file (with diff vals of course ;-)

I see that the val from main file is rendered in sub-file template output!!

This also puzzles me to no end - it contradicts what was found from changing "include_once" to "include" does it not???

Any further thoughts on this and my prev reply to you??

TIA,
Tom

Forgot to give you link to the test scripts

http://tomhenry.us/tbs/eztbs_snippets/main_page_ez2.php

You can see the source there -- and you can see the val from main file shows in subfile template output (lower left) and this is not the val set in the subfile php code.

> And another thing -- (maybe caused by the same issue) -- the 'same
> named' vars in the second script will contain the vals from the main script
> all the time.  If they were 'local' vars then I would expect the vals to be
> rendered in the second  template to have the local vals - but that
> is not the case.  Ideas?

No, Var fields (like [var.x]) can display only global variables. Nobody but the current function has access to this function's local variables.
That's why Var fields in the subtemplate display global variables instead of local variables. This is normal.

Okay, I understand it better now... please advise how I get those 'local' vars to display in tpl file (like in the menu sub-file in example we're discussing)

I need to learn to be able to display any vars calculated in the  sub-file in the sub-file's own template - i.e. how that is  different from displaying globals.

Thx so much for you help and patience in these things --- understanding all the little details is on the road to getting most from TBS.

[var.thanks.for.TBS],
Tom

PS -- back to the include_once issue -- you meant then that the $db_user, $db_passowrd, etc., vars (that came from the included file) were then actually  'local' vars? - local to the main script?  and thus unavailable to the sub-file?
I guess I don't get what makes them local and what makes the other vars declared in that script to be globals. ???

> I see that the val from main file is rendered in sub-file template output!!

This is all normal too.
Var fields (named [var.xxx]) display global variables. Global variables are the same for all script, function or sub-script. They are shared variables.

Hi Skrol

Maybe I was unclear/incompleyte in my question. Here's the thing about that...
$test_var is set to = "Main Script" in the main script
Then later in the subscript
$test_var is set to  = "Sub Script"

But in the rendered sub script template the val of $test_val is rendered as  "Main Script"

So the question still stands (at least in my mind ;-):  How do I display php $var=vals that are set in the sub-script?

You can see this all happening in real-time at
http://tomhenry.us/tbs/eztbs_snippets/main_page_ez2.php

What do you think about it?

Thx,

> How do I display php $var=vals that are set in the sub-script?

Declare the variable as global in the subscrit.

global $var2;
$varl2 = vals;

...

[var.val2]

Okay - let me test it (yes - that works) - so that must mean that all the script processing inside the sub-script is done from inside a TBS function - is that right? Well it must be - that was dumb of me not to see that was what was happening.
So that means somewhere TBS is 'globalizing' all the var/vals that are used in MergeBlock - I think I get it now...

Thx for your patience,

> so that must mean that all the script processing inside
> the sub-script is done from inside a TBS function - is that right?

Yes. In fact it couldn't be differently.

> So that means somewhere TBS is 'globalizing' all the var/vals
> that are used in MergeBlock

No. Fields merged with MargeBlock() are not Var fields.