>
> I suppose it's a result of smart deduction based on question why on
> earth you would want DBKEY in where clause as *literal* ? You can't make
> up DBKEY.

I'm not making it up, it comes from the query that the user is browsing
thru, then in the background I update the necessary record.

When then format the update as a literal and send it off you do it's work.

, you have to explicitly query for it first. Because they are

> transient, you can't keep them for later use, you have to use it right
> away in the same statement (or in very specific or insane situation in
> the same transaction) context. To meet that criteria, people usually do
> that as s part of their SP or application. In that case, the
> self-evident approach is to use result fields from query as bind
> variables for where clause in second statement, hence no need for
> literals. Only one valid scenario that one can imagine when you would
> need literal dbkeys is in interactive session (ISQL, whatever). You have
> got DBKEY on your screen, so you have to retype it as literal, but there
> is no real point to ever do that, because you can use PK instead with
> the same result. The small time saving you would get from use of DBKEY
> instead PK is pointless in interactive session. All in all, it leads to
> logical conclusion you want to use DBKEY because you don't have PK :-)
>
> > I know all of that, I just had a simple question of how to format the

value

> > into a literal string, so that I can update my records.
>
> Well, you can't. Guess what, because you don't ever need to do that. If
> you think you do, then read all replies to your question and think again.

Once again, stop trying to understand our business and just provide an
answer to the questions.

Just because you can't think of a reason why something isn't needed (today),
doesn't mean it's not needed.

>
> Yep, we could stop at the simple answer: YOU CAN'T DO THAT. But we're
> trying to be really helpful, and offer you a solution to your problem,
> instead of simple, correct, but no much helpful answer. I'm sorry that's
> disappoint you.
>

I'm not disappointed, just frustrated at all of the problems this database
has.

And most of you guys just prefer to argue than to look at the competition
and see that you will never be able to compete until you deal with all of
the speed issues and of basic functionality. And no, I'm not referring to
the issue of this thread.

Thanks