Re: Multi row blocks

Hi Mark,

I guessed you would respond thus, and myself and the rest of the team are with you. 'dave' does have some issues :)

And I believe you might have hit the nail on the head about him not wanting to find a solution.
Howevere, to be fair, we did employee the services of an Oracle consultant, who also couldnt provide any answers; all we basically got from him was, 'yeah, that shouldnt be a problem', but no idea as to how to do it.

The performance issue was also raised with Oracle, in front of our £9mil paying customer, to help add some weight to the problem, and Oracle looked at it and said, 'yep, thats a bug, we'll get on and fix it', only to be jumped on from Oracle USA who said, 'no we wont!'

I guess our problem is simply that we dont have the expertise, and when we tried to hire some, it left us with a bad taste.

Any links or pointeres to some functionaly rich 9i stuff might be a help. (or screen shots at least). We're just all struggling a bit to get the 9i environment to match up to our Functional Specification, and are thinking we should do it in something else, but what?

I hate thin client stuff, seems we take 10 steps forward in thick client development, only to be thrown back 10 leaps trying to run it all in a browser.

Many thanks
Jules

"Mark C. Stock" <mcstockX_at_Xenquery .com> wrote in message news:V_qdnWk36PwsXePdRVn-sA_at_comcast.com...
>
> "Julesm" <julesm_at_ip242yh.plus.com> wrote in message
> news:AVSec.29700$h44.4286475_at_stones.force9.net...
> | Hi again,
> |
> | I ran that by our forms man, and got the following?
> | Is he right do we think?
> |
> | -------------------------snip-------------------------------
> | Jules,
> |
> | Thanks for this, but as ever, these people are saying yes it can be done
> | using Oracle Forms or a Java grid. This seams to be a favourite
response,
> | but noone is ever prepared or able to point us at something that proves
> it!
> |
> | The first problem is where to get a java grid that will do what we want
> and
> | of course the problems that will inevitably follow implementing a grid,
> such
> | as bugs in the grid, Oracle and the Grid supplier blaming each other for
> any
> | problems, etc. etc.
> |
> | The other problem (and this will apply to both the grid and the non-base
> | table MRB) is going to be performance. It's all well to develop these
> things
> | on a small database on what is a reasonable sized application server
with
> | just a couple of developers connected over a 100MB network, but what
> happens
> | when the application is supporting 100's of users some over not much
more
> | than a 64K link? Very often, the developer solution is just to bung more
> | hardware at the problem (Microsoft!) but may not be possible here, and
can
> | never be the correct solution.
> |
> | I would take anything that you're told here with a large pinch of salt.
On
> | your other question (re: performance) the reply suggested that we remove
> | triggers from the form but we (STL) know that it is a bug in the
> Application
> | server, Oracle know it's a bug in the application server, but it appears
> | that the chap that replied does not!
> |
> | I hope to look into whether good, simple code can be written to provide
> the
> | functionality required (or palm the search off onto someone else!).
While
> my
> | gut reaction is no, I'm happy to be proven wrong!
> |
> | Regards
> | Dave.
> |
> |
>
> well, jules, i don't remember ever discussing this with 'dave' so i don't
> know about the 'as ever' part ;-)
>
> if 'dave' understands forms, my previous response about the non-base table
> block should be sufficient information about that technique -- if it's not
> sufficient for him, then you'll need to hire a consultant to mentor your
> forms guru <insert another wry smiley here>
>
> there is sufficient information about extending forms with java at the otn
> site -- 'these people' (or 'this people') suggested that approach as an
> avenue for investigation, but it looks like 'dave' wants the testimony of
an
> expert witness. whatever the case, it kinda appears that maybe 'dave' is
not
> real interested in finding a solution
>
> i'm not sure what the background is for the performance comments -- seems
> like a general complaint against not only oracle but also microsoft.
perhaps
> 'dave' had some bad coffee before he responded? whatever the case there, a
> slow client configuration will be slow against a big or a small database
> (it's the bad SQL, not a bad client software tool, that that scales poorly
> as the database gets larger). is 'dave' concerned about forms as a fat
> client in a client-server scenario? that would seem unlikely if he's
talking
> about dial up connections. if you're considering doing forms 9i via the
web
> server, then the user's network connection really has little additional
> impact on application performance (compared to other interface options),
but
> the communications link between the application server and the database
> would be a larger factor.
>
> i also don't know quite what the issue is with triggers and the
application
> server -- we deployed a nice robust forms 9i application on 9iAS release 2
a
> year ago for the state of virginia and never had any problems with
triggers
> on forms or the database.
>
> so -- hopefully 'dave' can find someone else to do his work and everyone
> will be happy.
>
> let me know if i can be of any further help (and keep a close eye on
'dave')
>
> ps: i tried to attach a large pinch of salt, but that functionality is not
> supported in a text-based news reader
>
> ;-{ mcs
>
>
>
>
Received on Fri Apr 16 2004 - 03:18:04 CDT