Google has now released a new service called "App Engine." Without having
even looked at it, I'm sure it's much better than, well, you know. (If you
are a fan of PeopleSoft App Engine, you might want to move along now.
Nothing to see here.)
A reader wrote to ask the old question: Which is faster, App Engine or SQR?
I've never seen any timings—just opinions. So I replied with my own opinion.
Since the time spent in processing SQL queries usually accounts for nearly all
of the run time of either an App Engine "program" or an SQR, it probably
doesn't matter one bit. However, App Engine makes row-by-row processing just
difficult enough that it tends to encourage code that uses more efficient
set-based processing. Now, SQR supports any type of SQL that App Engine does,
but SQR makes it much easier to code in any way you want—including the
inefficient way. If the encouragement
helps you to write efficient code, use App Engine.
The other day I was faced with the task of modifying an AE. The change was simple:
Add a field to a table (done) and then modify the SQL in one step of the AE to
populate the new field. This step uses the %InsertSelect meta-SQL construct,
so I needed to add an "override" parameter for the new field. I did that and
saved the SQL and submitted the program. It stopped with an error complaining
that the new field did not exist. In App Designer, "resolve meta-SQL" expanded
correctly to exactly what I wanted. I made a change to the SQL, saved and restarted
the AE. Same error, showing the same SQL as before (without the last change).
Deleted and reran. Same thing. Bounced the app server. Deleted from PS_AERUNCONTROL.
Changed the SQL again to something ridiculously invalid. Same thing. No matter what
I did, it kept using the version showing my first change. Eventually I migrated that
SQL from another environment and for some reason that worked (although we were
then back to the original version). Luckily we decided that that particular
change would not be needed after all, and the person who originally built the
AE would modify it in a different way. I later overheard him muttering about
needing to add a new effective-dated version in order to get around this problem.
That doesn't seem right (I've been able to make changes to AEs and restart
successfully many times in the past), but I'd appreciate any ideas you might have.
Update: Nigel replies that "It's due to the PSAESRV cache not having been updated with the table's new definition. We've experienced it on many occasions." Thanks!