Re: Import Designer 2000 Web PLSQLs into Designer 9i

Hi King,
[Quoted] [Quoted] Yup the web pl/sql toolkit was installed by default. We installed the Web PL/SQL Generator library onto the user schema and just compiled the old designer web code onto the database. And viola they are working! Though we havent tested all the screens, initial signs have been encouraging! Thats a relief. :)

We will be sticking to Option 2, as recreating all the modules on Designer 9i would take a hell lot of time. so we stick to the thankless job of manually editing these packages with no designer help!

About the Table APIs u mentioned,i havent been able to trace any api for the tables being updated from the screens in the current production system. Is that api is optional and can be done without? Atleast in the code there are simple insert/updates statements and no reference to cg$<table_name> procedures. Also, as i will be executing these as normal PLSQL packages are APIs needed at all?

[Quoted] Thanks for ur time
Raz

jhking <jhking_at_airmail.net> wrote in message news:<cbccjm$te0_at_library1.airnews.net>...
> Raz wrote:
> > Jeez, this indeed is a mess!
> >
> > There is no trace of the earlier repository anywhere :(
> > Also we are planning to move this application onto entirely new
> > machines and will be creating the database afresh in which case i
> > guess we have only the folliwng options.
> > 1. Create a new repository and create the application from scratch
> > using Designer 9i. This will take a considerable amount of work
> > assuming we have sufficient knowledge of the screens and database.
> > Thankfully the application as such is not humongous.
> > 2. Compile all designer built in packages (WSGL,WSGLM,WSGFL,WSGJSL and
> > associated objects) and designer application packages onto the Oracle
> > 9i database, directly edit the packages using standard PL/SQL editors
> > (changes are not minor but manageable) and compile the same. This as
> > pointed out will be regular PL/SQLs with no designer fucntionality.
> >
> > the second option is a crude way of doing things but will reduce
> > effort (&costs), provided it works and there are no incomptibilies
> > inbetween. In the end again, we will not have a repository and the
> > same problems will continue if future enhancements are made.
> >
> > But then will such a thing work, as we will not be using the Designer
> > toolset to code/install any of the objects, also would additional
> > configurations be required on the Web Server apart from setting up the
> > mod_plsql to listen to SQL requests?
> >
> > Have heard of a something of a Web PL/SQL toolkit.Can that help me in
> > any way here?
> >
> > Thank Raz
>
> htp, htf and some owa_% packages are the web pl/sql toolkit. They
> should be installed by default in any currently supported Oracle
> database. The wsg% packages, a package named cg$errors and the table
> api for your base table (if you're doing inserts or updates ) are
> necessary to get web pl/sql modules to run. The table api is a set of
> triggers and a package named cg$<table_name>, <table_name> being the
> name of your base table. If you have some publicly accessible place I
> could look at screen shots from your application I could quickly tell
> you whether it had been extensively modified or not. If it is pretty
> much wsg as generated you may have a shot at reverse engineering it, if
> its been hacked up, your option two is probably the only practical way
> to proceed.
Received on Fri Jun 25 2004 - 08:32:02 CEST