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.
> >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. ;)
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
