Supported non-functioning by PGDBE OrdKeyno and dbPosition

[digitsoft]

Hi Roger
These functions are not Supported by PGDBE OrdKeyno () and dbPosition()

Paulino Nolberto
A cordial greeting

[Auge_Ohr]

These functions are not Supported by PGDBE OrdKeyno () and dbPosition()

and also OrdKeyCount() is missing in Xbase++ ( PDR 5206 still open ... )
but thats not Rogers Problem ... it is Alaska so write into Newsgroup "preview.xbase++.20"

SQL does not have ISAM Style "Position".
PostgreSQL v8.3 does not have Function to support a Way to simulate it.
PostgreSQL > v9.x does have ROW_NUMBER() Function and can be used this Way in a SQL Query

Code: Select all

   cQuery := "SELECT " + cField +;
               ", row_number() OVER (ORDER BY " + cOrder + ")"+;
               " FROM " + cTable + ;
               IF( EMPTY( cWhere ), "", " WHERE " + cWhere ) + ;
               " ORDER BY " + cOrder

this will create a extra Column which you can access this Way

Code: Select all

METHOD JimBrowse:DbPosition()
LOCAL cDBSfield := "row_number"                  // from row_number() as extra Column (only at Runtime )
LOCAL nRowPos   := 0
LOCAL nIsRec    := 0
LOCAL nOutRec   := 1
LOCAL cfield    := ""

   // Cursor on hilite Row
   nRowPos := ::_nRowHilite
   // ZERO based Index
   ::oResult:goTo( nRowPos - 1 )
   //
   // row_number()
   // number of the current row within its partition, counting from 1
   //
   nIsRec := VAL( ::oResult:DataBlock( cDBSfield ) )
   IF nIsRec > 0
      nOutRec := nIsRec
   ENDIF
   //
   // original DbPosition work from 1 to 100
   // here i do NOT do calculation to 100%
   // please put YOUR Code here
   //
RETURN nOutRec

[skiman]

Hi,

I thought that with the use of the UPSIZE tool the recordnumber was saved in a specific column.

[Auge_Ohr]

I thought that with the use of the UPSIZE tool the recordnumber was saved in a specific column.

yes, there is a internal field "__record" create when using DbfUpSize.EXE but what do you expect from "__record" in a Index / Order ?

IMHO those internal "__" field are bullshit and a bad Workaround from Alaska for there ISAM Stuff.
it is a big Overhead to support those internal "__" field when Record are updated and you get in Trouble
with other ( not pgDBE ) Client with access PostgreSQL Table too while there is no external Trigger to use.

Alaska have take Phil Ide Sample from 2003 using PostgreSQL v7.x and later v8.x and build there pgDBE.
i have insist many times to use PostgreSQL v9.x but Alaska still refuse it and kick me of Alaska Newsgroup ( but i have more Accounts to read )
Alaska are not PostgreSQL Professional. They do learn it now by making beta Stuff which you can pay for Subscription.

if you real want to use PostgreSQL i recommend to learn Postgre and read e.g. ISBN 3-8266-1337-6 and ask in special PostgreSQL Forum.

[digitsoft]

Write reply Delete
Re: These functions are not Supported by PGDBE OrdKeyno () and dbPosition()
on Wed, 09 Oct 2013 18:01:01 +0200

Nolberto,

we need to postpone these functions to a later point for performance
reasons. Implementation of them in the context of a SQL server is rather
complex and we need to find a way to realize them with acceptable
performance.

However dbposition() and dbgoposition() are working SQL result set,
therefore you can use as a workaround instead of creating a filter/index
with for condition use the SQL SELECT command with a WHERE and ORDER BY
clause. Then orderkeyno equals record# and dbgoposition and dbposition work
properly.

Anyway, we will provide these two missing features in the context of logical
orders with CTP4 and one of the refresh.

With kind regards
Steffen F. Pirsig
Alaska Software

"Nolberto Paulino Esterell" wrote in message
news:22348673$3c4a0b6$116f@news.alaska-software.com...

Hi The Group
These functions are not Supported by PGDBE OrdKeyno() and dbPosition()

Paulino Nolberto
A cordial greeting

_________________
Nolberto Paulino
Regards

[Auge_Ohr]

hi,

we need to postpone these functions to a later point for performance
reasons. Implementation of them in the context of a SQL server is rather
complex and we need to find a way to realize them with acceptable
performance.

seem Alaska still search for a Way ...

However dbposition() and dbgoposition() are working SQL result set,
therefore you can use as a workaround instead of creating a filter/index
with for condition use the SQL SELECT command with a WHERE and ORDER BY
clause. Then orderkeyno equals record# and dbgoposition and dbposition work
properly.

hm ... Resultset is like a Array and can have more than 100 ROWs
DbPosition() just work from 0 to 100 so most it not the real ROW / Record.

DbfUpSize does store Recno() and IndexKey() in internal PostgreSQL Fields as "Function Index".
these internal Fields must be update by ISAM Stuff and make a lot of Overhead.
as i show you can use PostgreSQL ( v9.x ) SQL Function "on-fly" and use real Index instead of "Function Index".

i love Idea of pgDBE but IMHO that ISAM Stuff is overload.
you may be "transfer" a small Demo Application but not a big working Application ...
you have much more limitation than using "native" libpq.dll or SqlExpress++ ... same API like pgDBE

PG API just make Connection, send Query and get Resultset. nothing else is need to work with PostgreSQL.