>confused
> > on your workaround. Are you saying that if you define the user name and
> > password in the MX Administrator then you don't get the error? If so,
>that's
> > not what I'm seeing. I define the user name and password in the MX Admin
>for
> > my datasource and still see thing problem. Again though, I may be
> > misunderstanding what you mean.
>
>Yep, that's what I'm saying. However, I'm not sure if we were seeing the
>_same_ error that you were seeing. (I don't actually know what our error
>was.) Our typical setup is that we had a single generic DSN for the oracle
>box, and then each developer would pass their own schema name and password
>from within the cfqueries. When we switched to having individual DSN's for
>those people that couldn't get rid of the cftransaction tags, the errors
>stopped.
That's an interesting setup. Alas, we only ever used the username/password
features in the MX Administrator, so our environments are slightly
different. I continue to see the removeOnExceptions error with just the
Admin login.
>
> > >We've resorted to doing that for some apps, and moving transactional
>logic
> > >to stored procs for others. No fun. But, it's the only solution we've
>come
> > >up with so far (Oracle 8i).
> >
> > Yeah, I've been pushing to move our SQL, particularly the transactional
> > queries, entirely into Oracle packages. However, I'm a one-man show as
>far
> > as CF development at my company, so getting the time to refactor my
> > inherited code base is slim to none at this point.
> >
>Right there with ya. We have something like 8 GB of html and cfm code,
>managed by 3 full time staff and one student. Nothing gets refactored
>unless
>it's seriously broken. ;)
Glad to know I'm not alone!!
Regards,
Dave.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
