[EMAIL PROTECTED] wrote:
> > > Hello,
> > >
> > > My table is as follows:
> > >
> > > CREATE TABLE "ABN"."TL"
> > > (
> > > "ID" Integer DEFAULT SERIAL (1),
> > > "TEKST" Varchar (20) ASCII,
> > > PRIMARY KEY ("ID")
> > > )
> > >
> > > Manual page - 197 - says:
> > >
> > > "INTO <parameter_spec> is not necessary in interactive mode."
> > >
> > > Neiter works:
> > >
> > > SELECT DIRECT * FROM "TL" KEY ID=1
> > > SELECT DIRECT "TEKST" FROM "TL" KEY ID=1
> > >
> > > This works:
> > > SELECT * FROM "TL"
> > >
> > > What am I missing?
> > >
> > What is the error returned ?
>
> SELECT DIRECT * FROM "TL" KEY ID=1 => -5015 Missing keyword:
> FROM, WHERE
> SELECT DIRECT "TEKST" FROM "TL" KEY ID=1 => -5015 Missing
> keyword: YEARS,
> WRITE, WORK, ...
>
> >Which SQLMODE do you use ?
>
> Internal
>
> > Which client (JDBC/SQLStudio/...) do you use?
>
> SQLStudio 7.4
>
> > You are aware that with the next MAJOR
> > release (7.4.*) SELECT DIRECT
> > will not be available any more ?
>
> Of course I don't.
> Is there a list of planned changes around?
>
You are right, it is said, that interactive mode does not need
INTO <parameter list>
But unfortunately SQLStudio handles every statement in a way
that the kernel is not aware of the interactive state, but believes
to be in the INTO-is-needed state.
If you will now try to fill in INTO :parameter you will not succeed, too.
SQLStudio will tell you : Error occured, invalid cursor state.
--> with SQLStudio you will have no chance to work with select direct.
But let us check why you wanted to use select direct and no
'normal' select resp. cursor:
> ---------
>
> Let me explain what I am after: If primary keys were immutable,
> transactions doing queries with WHERE predicates in the form
> ID= 123456 ( I
> mean exact PK value) would not need to lock the whole table.
> Hmm, except
> for queries for nonexistent rows maybe. This is probably a
> special case of
> predicate locking, but would boost my applications the whole lot.
Oh, my goodness, who told you that the whole table will be locked
for the query with WHERE ID = 123456 ?
YOU have the chance to decide how much will be locked.
With the different isolation levels you are using, you can specify
what you want. With the default-isolation level (named COMMITTED
in SQLStudio, named ISOLATION LEVEL 1 in the reference manual
of the kernel) you will NEVER lock the whole table.
You will usually not even lock your row, just check if another guy
is changing it (not having done the commit/rollback) and only in
special cases lock that single row.
Therefore I think select direct is not necessary for your needs.
We will check here if it is easy to allow SQLStudio to handle
select direct. But as I told you (and it is written in the archive ones
or twice, therefore I thought you may have read this) with the next major
release select direct will not exist any more. Therefore I do not
know if we will do much work for making this feature available
for the time remaining.
Elke
SAP Labs Berlin
> Regards,
> Wojtek
>
>
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
