y to do this without slicing up the
>post-deployment orion generated files.
>
>-Original Message-
>From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
>Sent: Friday, December 28, 2001 10:26 AM
>To: Orion-Interest <[EMAIL PROTECTED]>; Aaron Tavistock
>Subject: Re: [orion-interest]
y than is practical in the majority of
situations, IMHO).
-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 28, 2001 12:32 PM
To: Aaron Tavistock; Orion-Interest <[EMAIL PROTECTED]>
Subject: Re: [orion-interest]EJB2.0 spec or implementation?
On 28/12/01 3:2
8, 2001 10:26 AM
To: Orion-Interest <[EMAIL PROTECTED]>; Aaron Tavistock
Subject: Re: [orion-interest]EJB2.0 spec or implementation?
On 28/12/01 12:56 pm, "Aaron Tavistock" <[EMAIL PROTECTED]> wrote:
> So heres the story - database field names are case insensitive, so comm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neither is Oracle. Oracle actually stores all its DB Fields upper case, but
it doesn't matter how you refer to then, meaning select column1 from Table
or select Column1 from table or select COLUMN1 FROM TABLE Doesn't make a
difference.
R
At 01:
On 28/12/01 12:56 pm, "Aaron Tavistock" <[EMAIL PROTECTED]> wrote:
> So heres the story - database field names are case insensitive, so common
> parlance for representing a space is an underscore (e.g. 'this_field').
Nope. MS SQLServer is not case insensitive. You could always tweak
orion-ejb-ja
I've toyed with EJBs for quite a while, all the way back to 1.0. But so far
its been too cumbersome and offered little gain in most environments I've
been working in (e.g. the overhead of remote calls, etc, outweighed the
potential benefits).
Now with the 2.0 spec its gotten to a good place wher
