Roberto's reply provides me with verification that the problem I've been experiencing with some of my Portal Tables (which are ADP scripts) is somehow directly linked to the fact that AOLserver caches the ADP scripts in memory. Yes, there is a potential problem, unless of course I'm missing something.
The following script, which is the code for a portal called "Region",
<%
set user_id [ad_verify_and_get_user_id]
set selection [ns_db select $db "
select group_name, short_name
from user_groups ug, user_group_map map
where ug.group_type = 'Region'
and ug.group_id = map.group_id
and map.user_id = $user_id"]
ns_db getrow $db $selection
set_variables_after_query
ns_puts "<B>$group_name</B><BR>"
ns_puts "<a href='/groups/$short_name/calendar/monthly.tcl'>$group_name Calendar</a><BR>"
ns_puts "<a href='/groups/$short_name/address-book/'>$group_name Contact List</a><BR>"
ns_puts "<a href='/groups/$short_name/news/'>$group_name News</a>"
%>
is fine when you access it under
/portals/admin/edit-table; there are no error messages relating to problems with ADP parsing, and the table looks like it should. However, if you access it from an actual portal a little while later, the
$group_name and
$short_name variables disappear! (They're replaced with null values, or something of the sort, so the table still gets parsed, but all references to Regions -- the group names that are supposed to be there -- disappear. BTW, there
is a group_type called 'Region' in my installation, in case anyone wonders.)
Anyone have ideas about what I might be missing in this example, and/or possible workarounds? (The example is missing the usual calls to ns_db gethandle and releasehandle because, to the best of my understanding, those are covered with the Portals code itself.)
