Re: Access Frontend - Case Sensitivity

It's certainly an interesting idea. But it means an awful lot of code in the front end, which is exactly what I don't want.

So far, I've got 30-odd tables with stacks of constraints, triggers, procedures and indexes. All that's in Access are bits of form navigation code. If I wanted to re-develop the thing in Java tomorrow, I could. Start doing things this way, and I have a lot of code to port (or at least to carry) across.

I'm beginning to think that the instead of trigger might be the way to go.

Regards
HJR "Jim Kennedy" <kennedy-family_at_attbi.com> wrote in message news:xSPR8.59904$EP.5254_at_sccrnsc03...
> That is a good idea. An improvement on your idea would be to use bind
> variables. Then you would start smoki'n.
> Jim
> "Bricklen Anderson" <bricklen_at_shaw.ca> wrote in message
> news:3D1770C8.7047D139_at_shaw.ca...
> > Hi Howard. I'm currently working on an Access front-end (GUI for
> > internal users). Due to Access' annoying habits/locking/commits, I've
> > just used command buttons for all code that is executed. Eg. When the
> > Save button is pushed, it fires off (for example):
> >
> > ...
> > DoCmd.RunSQL("INSERT INTO t VALUES
> > (Ucase(name),number,valueA,Ucase(valueB))")
> > ...
> >
> > This allows me to dictate what needs to be uppercase on for inserts (or
> > updates).
> >
> > No problems over the last 3 months with it.
> >
> > Not that I know much about Access except what I've had to learn over the
> > past few months to work in it (as the front-end).
> >
> > hth
> >
> > Bricklen.
> >
> > if you need clarification etc, just drop me a line.
> >
> > "Howard J. Rogers" wrote:
> > >
> > > Something along these lines has been posted regularly in the past.
"Can
> > > Oracle be made case insensitive?" To which the reply is a perfectly
> > > satsifactory "No". (And if your name is Sybrand, followed by a swift
> "This
> > > is the real (case-sensitive) world!").
> > >
> > > Anyway: I don't want Oracle to be case insensitive. I just want to
make
> sure
> > > that my front end only sends upper case to the back end. Easier said
> than
> > > done when your front end is Access (and no, there's no chance at the
> moment
> > > of changing that!).
> > >
> > > For each field in Access, you can set a "Format" property. Set it to
> ">",
> > > and the field is forced to display things in uppercase. Sod all good
> that
> > > does: despite what it displays, it still sends whatever you enter (ie,
> mixed
> > > case) to the back end before displaying it in uppercase, and that's no
> good.
> > >
> > > I've tried Access' 'before insert' event -
> me!areacode=ucase(me!areacode).
> > > Doesn't work.
> > >
> > > I've tried a daft "After Insert" trigger in Oracle that does a 'after
> insert
> > > on X update Y set areacode=upper(areacode)' -but of course, that
results
> in
> > > a mutating table. I know I could fix that with a view and an
appropriate
> > > 'instead of' trigger... but I'd rather not have to create such a view
> and
> > > such a trigger for each of my 20 or so lookup tables. Too much
> maintenance.
> > >
> > > I've also tried a before insert trigger whose essential line reads:
> > >
> > > :new.AREACODE := upper(:new.AREACODE);
> > >
> > > ...which works, but gives Access a heart attack (the freshly-inserted
> record
> > > is displayed with all fields showing "#Deleted") -and a simple
> requery.me
> > > refuses to display the real record with real values. Close the form
and
> > > re-open it, everything's fine.
> > >
> > > Any other suggestions? Preferably easy to code and easy to maintain.
> > > Preferably in the backend rather than the front, but also preferably
> > > something that doesn't then give Access the eebie-jeebies (like
> displaying
> > > "#deleted" for every field).
> > >
> > > All help appreciated.
> > >
> > > Regards
> > > HJR

>
> Received on Tue Jun 25 2002 - 03:40:57 CDT