SQLExpress - Xb2.NET     ot4xb  
   Announcement      Free XUG Meeting Toronto/Canada (May 25, 2008)       [ More Info ... ]
sqlexpress
Re: :Recno() alternative?
Thread Starter: Mahanimann Started: 9/9/2006 2:38 AM UTC
Replies: 4
9/9/2006 2:38 AM UTC
Re: :Recno() alternative?
Reply Quote

Mahanimann

:PrimaryKey is a PROTECTED instance var. You can access this ivar if you
subclass from SQLDataSet.

Ok.  But why have you not made it reachable through a method? (Remember, I'm a newbie)

Mahanimann
9/9/2006 4:55 PM UTC
Re: :Recno() alternative?
Reply Quote

Mahanimann

In SQL you don't need an index you can request sets of records in any
order with any filter. Having an index speeds things up. Generally

Yes I know. I must have expressed myself wrongly.

What I mean is when you f.ex. use a generic sort-function, you need to :GoTo(nTheActiveRecnoBeforeTheSort) after the sort.  But, the :Recno() numbering change with the sort order, so one can't use :GoTo(). When you can't use :GoTo(), you need another unique value to seek on.  When the environment is generic, you need to know where to find that unique value within the oCursor.

That's where my question about :aPrimaryKey comes in.  If I could access oCursor:aPrimarKey in the generic sort-function, my "problem" is solved. Of course it is simple to overcome this, but why code extra for something that is allready there.  I do define :aPrimaryKey in all cursors.

That is one part of my question, oCursor:aPrimaryKey is there, so why not use it? (and why not give access to it?)

The other part is:  How do seasoned SqlExpress'ers handles situations where they need to go back to a specific row/record (after f.ex. a change in a browse sort order).  The function is generic, so it has no clue about which table it is sorting.  The sort-function only recives oCursor as a parameter.

I'll be more specific in my phrasing from now on :-)

Thanks for any reply,
Mahanimann
9/9/2006 4:32 AM UTC
Re: :Recno() alternative?
Reply Quote

James Loughner

The primary key is a property of the SQL engine. ie you set it when you
create a database.

In SQL you don't need an index you can request sets of records in any
order with any filter. Having an index speeds things up. Generally
indexes are set by usage patterns and not by the programmer.

There maybe a primary key defined which defines a default order
generally this should be on a unique value.

You can simulate record numbers by sequentially numbering a field.

You should read some of the links the Boris provides on his site about SQL.

Jim

Mahanimann wrote:
> :PrimaryKey is a PROTECTED instance var. You can access this ivar if you
> subclass from SQLDataSet.
Ok.  But why have you not made it reachable through a method? (Remember, I'm a newbie)
Mahanimann  
9/9/2006 5:34 PM UTC
Re: :Recno() alternative?
Reply Quote

James Loughner

Well you could just open a new cursor do what is needed there and your
original has never left the base row. Just go back to the original cursor.

Jim







Mahanimann wrote:
> In SQL you don't need an index you can request sets of records in any
> order with any filter. Having an index speeds things up. Generally
Yes I know. I must have expressed myself wrongly.
What I mean is when you f.ex. use a generic sort-function, you need to :GoTo(nTheActiveRecnoBeforeTheSort) after the sort.  But, the :Recno() numbering change with the sort order, so one can't use :GoTo(). When you can't use :GoTo(), you need another unique value to seek on.  When the environment is generic, you need to know where to find that unique value within the oCursor.
That's where my question about :aPrimaryKey comes in.  If I could access oCursor:aPrimarKey in the generic sort-function, my "problem" is solved. Of course it is simple to overcome this, but why code extra for something that is allready there.  I do define :aPrimaryKey in all cursors.
That is one part of my question, oCursor:aPrimaryKey is there, so why not use it? (and why not give access to it?)
The other part is:  How do seasoned SqlExpress'ers handles situations where they need to go back to a specific row/record (after f.ex. a change in a browse sort order).  The function is generic, so it has no clue about which table it is sorting.  The sort-function only recives oCursor as a parameter.
I'll be more specific in my phrasing from now on :-)
Thanks for any reply,
Mahanimann  
9/9/2006 7:32 PM UTC
Re: :Recno() alternative?
Reply Quote

Mahanimann

Well you could just open a new cursor do what is needed there and your
original has never left the base row. Just go back to the original cursor.

In my app I have (up to now) approx 100 tables where almost all of them need a data entry/edit window with a pop-up browse. I'm .NOT. making 100 different data entry windows and another 100 different browsewindows, I make 1 generic of each. The browse-window is reached by clicking a button.  In the browse the user can seek, change the sort order and even edit most fields. This is the browse calling code simplified as I would do with DBF:
************************************
nRecno := oCursor:Recno()
IF GenericBrowse("Items",oCursor)
   * The user chose an item:
   UpdateDataEntryWindow(oCursor)
ELSE
   * The user aborted the browse,
   * go back to the original one:
   oCursor:GoTo(nRecno)
ENDIF
************************************
Now, with SQL the :Recno() is not usable in this case because :Recno() changes with the sort order.  What I would like to do is this:
************************************
aUniqueKey := FieldGet_From_aPrimaryKeyFields(oCursor)
IF .....
   * The user chose...
   ......
ELSE
   * The user aborted the browse,
   * go back to the original one:
   GoBackToOriginalRecord(oCursor,aUniqueKey)
ENDIF

FUNCTION FieldGet_From_aPrimaryKeyFields(oCursor)
aUniqueKey := {}
FOR n := 1 TO LEN( oCursor:aPrimaryKey )
   cFieldName := oCursor:aPrimaryKey[n]
   xFieldVal := oCursor:FieldGet( cFieldName )
   AADD( aUniqueKey,  xFieldVal )
NEXT
RETURN aUniqueKey
************************************

But this is not possible either, because :aPrimaryKey by some reason is not accessable.  Boris said it would be accessable if I subclass from SqlDataSet. I will try that, but I still don't get why aPrimaryKey is not reachable.

I'm sure this subject is trivial for you gurus, but SQL behaviour is pretty strange for old DBF'ers like me.

So again, thanks for any suggestion.
Mahanimann