Re: update a 200 - 300 row table - APEX

From: Bill Ferguson <>
Date: Tue, 9 Jun 2009 06:34:19 -0600
Message-ID: <>

In addition to Mathias' suggestions, here's what I've been doing over the last 4 years or so.

Before designing an app, think long and hard about everything that is needed immediately (usually a separate 'page' for each aspect), and what features may be desired later down the road, and document all of these (i just use a simple spreadsheet).

Then, break up the pages into sections, like all search pages will be pages 120 - 140, all system (application) maintenance pages will be pages 1 - 110, etc. leaving plenty of exra pages in each section for future expansion.

Future maintenance is actually fairly simple. My 'main' app has most of the processing code in triggers and procedures.

I have about 35 data tables and around 20 lookup tables, with 71 web pages in the app. I am just finishing up my newest search page, for a total of 4 different options. This one will allow the user to specify some spatial criteria, along with the other 'regular' criteria. I've also built-in the abaility to take a Google Earth polygon and convert that into Oracle Spatial format for searching, and also create KML file outputs for Google Earth.

The most complicated part of my app was the searching features users wanted. Simple editing, etc. is child's play. After you get familar with Apex, you'll probably start moving towards creating your 'reports' manually, instead of through the wizards. You get a little more control over how things work without some of the restrictions the wizards require you to make (like only three fields allowed for primary key).

The Apex forums at are a great source for getting answers fast, from both other users and from the developers of the product.

Any further questions, feel free to ask away, probably off-line unless the question could be beneficial to the others on this list.


Received on Tue Jun 09 2009 - 07:34:19 CDT

Original text of this message