| Subject | Re: [firebird-support] Re: Updating with rdb$db_key |
|---|---|
| Author | Pavel Cisar |
| Post date | 2005-07-13T11:59:21Z |
buppcpp@... wrote:
earth you would want DBKEY in where clause as *literal* ? You can't make
up DBKEY, 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 :-)
you think you do, then read all replies to your question and think again.
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.
best regards
Pavel Cisar
IBPhoenix
>> I mean that tables without primary keys must die! It is well knownI suppose it's a result of smart deduction based on question why on
>>mantra in RU.DELPHI.DB: "table must have a primary key".
>
> What are you talking about??
> My tables have primary keys. Using RDB$DB_KEY is suppose to be the fast way
> to update a row, so that what I trying to do.
>
> Where did you hear me say that I had no primary keys?
earth you would want DBKEY in where clause as *literal* ? You can't make
up DBKEY, 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 valueWell, you can't. Guess what, because you don't ever need to do that. If
> into a literal string, so that I can update my records.
you think you do, then read all replies to your question and think again.
> Gee, you guys make a mountain out of a mole hill about everything.Yep, we could stop at the simple answer: YOU CAN'T DO THAT. But we're
> Stop reading so much into every post and just answer the question if you
> know the answer.
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.
best regards
Pavel Cisar
IBPhoenix