
#: 84438 S14/Paradox - General
    08-Jun-89  09:04:30
Sb: #84374-Auto number field
Fm: Tim Colling (BorApp) 76044,645
To: Christine Van Valkenburg 75715,1043

Christine:

Unfortunately, there is no such facility built-in to Paradox.  Therefore, you
have to construct it yourself with PAL.  For smaller tables, this will work
fine:

 setkey -20 []=cmax(table(),field())+1

This sets the alt-t key as a hotkey to autoincrement the value of the field
that the Paradox cursor is currently in.  Thus, it is a technique you'd use in
interactive Paradox.  Of course, you could change the setkey to any hotkey
sequence that you'd like to use. A drawback to this approach is that the big
tables.

The other approach uses PAL more extensively, and is the sort of thing you'd
typically use when the user's interaction is entirely under program control.
In this approach, you store the last-used number in an entirely separate
place, either in a separate table or in a variable that you load when the
program starts up, perhaps with a SAVEVARS script.  Then, whenever the user
opens up a new, blank record to work with, the program would

 (1) interrogate that separate storage location for the last-used number,
 (2) increment it by 1
 (3) store it back in that separate storage location
 (4) assign it (with it's now-incremented value) to the field that we wanted
     auto-incremented in the first place.

Regards, Tim





#: 84459 S14/Paradox - General
    08-Jun-89  10:24:22
Sb: #84374-Auto number field
Fm: Steve Reiss 76424,1007
To: Christine Van Valkenburg 75715,1043

Christine,

There is no Paradox feature to automatically increment a field.  You can use
SETKEY however to do this.  Create a script called INIT and include the
following :

SETKEY 14 PgUP x=[] PgDn []=x+1

This will work if you are in edit mode in FORM view on a keyed table. The
field to be incremented must be numeric.  When you are in this field, press
<Ctrl-N> and the desired value will be assigned. (You will have to put a "1"
in the first record to start with).

If the table is non-keyed, use the following line in the INIT script:

SETKEY 14 []=CMAX("TableName", "FieldName") + 1

TableName & FieldName should be replaced with your table names.  This example
will work in Form & Table view while in Edit mode.  CoEdit or Data Entry modes
require a more complex script.

   Hope this helps!

   Steve




#: 66883 S14/Paradox - General
    01-Mar-89  20:49:44
Sb: #66567-Auto-numbering
Fm: Larry Lynn 71401,1374
To: Michael Satterwhite 76357,720

Michael,

This depends on your data entry script; since you are looking for a tie
breaker field for records with duplicate keys, create a 3rd keyed field called
[Tiebreak] and use something like this at data entry:

  Wait record until "F2", other keys ...
   Switch
      Case retval="F2":
           c=1
          While true
             Lockrecord
             IF retval=False THEN     ;false if key conflict
                 [tiebreak]=c       ;place a number in the field
             Else
                Quitloop
             ENDIF
             c=c+1               ;increment c in case still duplicate.
           ENDWHILE
          Do_IT!      ;or whatever post entry processing you want

      Case .....
   ENDSWITCH

Larry



#: 79141 S14/Paradox - General
    07-May-89  10:41:58
Sb: #78850-Autoincrement a field
Fm: Brian J. Smith 75530,332
To: Don Schubert (BorApp) 72767,1465

CMAX is accurate, but it's slow.  With a 10,000-record table on my 12-MHz 286
PC, each call to CMAX takes 12 seconds.
   Therefore, I prefer the following method for auto-incrementing a field:

        SetKey 14  CtrlBackspace Ditto []=[]+1

This small script (activated, like yours, by the Ctrl-N key) assumes that you
enter new records at the bottom of the table, below the last record.  It
"dittos" the value from the record above, then adds one to it.

#: 79198 S14/Paradox - General
    07-May-89  17:37:56
Sb: #79142-Autoincrement a field
Fm: Ben Sevier 34275,4
To: Brian J. Smith 75530,332

Brian - I gave up on CMAX for incrementing, but the IMAGECMAX function really
f flies along (should, usually not many records to scan). Since most of my
data entry tends to be in embedded forms nowadays, it works great.

Just thought I'd pass it on.

Later, Ben

#: 74471 S14/Paradox - General
    11-Apr-89  09:48:01
Sb: #74418-Pdx3
Fm: Celeste Robinson(BorApp) 76701,126
To: jose jacques 75530,3712


Create a script called init if you don't already have one and include the
following line:

SETKEY 14 PgUp x=[] PgDn []=x+1

This will work if you are in EDIT mode in FORM view on a keyed table.  The
field to be incremented must be numeric.  When you are in this field, press
Ctrl N and the desired value will be assigned to the field.  (You have to put
a "1" in the first record.)  If the table is non-keyed, use the following line
in the init script:

SETKEY 14 [] = CMAX("Table","Field") + 1

"Table" and "Field" should be the literal names of the table and field in use.
The second example will work in FORM or TABLE view.  You must be in EDIT mode.
COEDIT or DATA ENTRY modes require a more complex script.



#: 72488 S14/Paradox - General
    29-Mar-89  23:25:19
Sb: #72363-autoincrement/multitable
Fm: Dan Ehrmann (BorApp) 72571,3533
To: Don Schubert (BorApp) 72767,1465

Don:

The problem with the script you are using is that it is trying to perform the
assignment while a new record is unposted, or while an existing record is
locked.  Multi-table forms enforce the Link-Lock, which prohibits you from
working with other tables on the workspace under these circumstances.

You may need to break the routine up into two stages, one to grab the number
and assign a new one, before each record is entered, the other to take the
number and insert it into the table.

-Dan



#: 72502 S14/Paradox - General
    30-Mar-89  04:48:07
Sb: #72363-autoincrement/multitable
Fm: Tim Colling (BorApp) 76044,645
To: Don Schubert (BorApp) 72767,1465

Don -

You may have to moveto the image containing the value you need to look up,
increment it and write it back, and then return to the starting position and
fill in the field you started from.

Regards, Tim

#: 72688 S14/Paradox - General
    30-Mar-89  19:22:33
Sb: #72363-autoincrement/multitable
Fm: Larry Lynn 71401,1374
To: Don Schubert (BorApp) 72767,1465

Don,

Yes, aren't multi-table forms fun?  The easiest answer to your problem is to
place the Numb table into the multi-table form as an unlinked table. In order
to get a value from a table not on the form, you must be in table view; you
can only flip to table view if your record isn't locked. So, you must either
1) get the number before entering any information about the record or 2)Enter
the record and issue a LOCKRECORD UNLOCKRECORD combination in order to unlock
it without haveing it fly away. This code should do it; If you want to enter a
number for the current record, take out the INS; if you want to enter a number
for the next record, leave it in and take out the LOCKRECORD, since you won't
care if the record flies away.

     Lockrecord   ;assumes you've entered data; necessary to keep cursor
     Unlockrecord ;with record.  UL lets you leave formview.
     Formkey
     x=[Numb->numb]
     [Numb->numb]=x+1
     Formkey
     INS          ;This will enter number for NEXT record
     IF isblank([fieldname]) ;just in case something goes wrong.
       [fieldname]=x ;without INS, this will go in the record just entered
     ENDIF


Larry


#: 72728 S14/Paradox - General
    30-Mar-89  23:38:27
Sb: #72589-autoincrement/multitable
Fm: Dan Ehrmann (BorApp) 72571,3533
To: Don Schubert (BorApp) 72767,1465

Don:

No way to turn the locks off; they are built into Paradox.

To read the value, use code like:

   moveto "CONFIG"
   XXX = [Next Number]
   [Next Number] = XXX + 1
   moveto "DATATABL"

To put the results into the table, after you have opened up a new record,

   [ID Number] = XXX

<grin>  -Dan




#: 60731 S15/Paradox - PAL
    25-Jan-89  12:22:11
Sb: #60691-*.px files
Fm: ALAN ZENREICH 71171,1340
To: Dan Ehrmann 72571,3533

Dan, it is worth pointing out that Restructure has a by-product of removing
any rotations that were stored as part of a {Keepset}.  A quick way to make
sure your rotations stay in effect after the restructure is (if there are in
fact any rotations kept in a .SET file)

1)  CREATE "answer" like ztable  ; or
    MENU {Create} {Answer} {Menu} {Borrow} select "yourtabl" DO_IT!
2)  Menu {Tools} {Copy} {Justfamily} SELECT "Yourtabl" Select "Answer"
    {Replace} ; now answer has  rotations
3)  Do the restructure to pack the data as you've outlined
4)  Menu {Tools} {Copy} {Justfamily} SELECT "Answer" Select "Yourtabl"
    {Replace} ; brings rotations back to the original table
5)  Delete "Answer"

I have a few other techniques that handle this without the overhead of
creating a temporary table, but the notes above work well for the
interactive user.

#: 60729 S15/Paradox - PAL
    25-Jan-89  12:21:10
Sb: #60666-#AutoInc Script Fixed
Fm: ALAN ZENREICH 71171,1340
To: David Lewis 70105,1242

; message 1 of 2

; David, here is one of several versions that I have developed.
; This proc assumes that a single record table is on the workspace, with a
; structure something like  [Next Invoice#], [Next employee ID#] that simply
; holds next numbers to use.
; It also assumes that we are in coedit mode along with the table that we are
; trying to get the next number for.
; I use this technique to store a variety of "next numbers", including dates.
; Basically, when a request for a next number is made, I jump up to the
; nextnumber table, move to the appropriate field, grab the number, increment
; it for next use, move back to my data table, and drop in the value.
; If it is unable to lock the record within 5 seconds it will return
; "Error"  If it returns Error, consider putting Erroruser() into the error
; prompt
; **** In the form below, it assumes that we are already in CoEdit mode.*****

; it is typically invoked as
  z=azNextNumber("Nextnum","Next Invoice#",1,"Getting next invoice number")
  if z<>"Error" then
    [invoice#]=z
  ; else             ; perhaps do some other errorchecking or tk stuff
  ;  tkaccept=false
  endif

PROC azNextnumber(ztable,zfield,zincrement,zworkingmessage)
  PRIVATE z,         ; loop counter
  zoldtable,    ; original table name
  zisformview   ; original form status
  ; ztable is the name of the table that contains fields for nextnumber
  ; zfield is the name of the field with the next number to use
  ; zincrement is typically a number
  ; zworkingmessage is message to display while getting the next number

  @0,0 clear eol
  Style blink ??"..."
  @1,0 Clear eol ??zworking  ; displays a message while it gets the number
  zoldtable=TABLE()          ; find the original table name
  zisformview=IsFormView()   ; let's me put it back
  IF NOT IsValid() THEN
    Ctrlbackspace  ; clear the field so we can move
  ENDIF
  MOVETO ztable
  MOVETO FIELD zfield
  FOR z FROM 1 TO 10
    LockRecord
    IF RETVAL THEN    ; no one else is doing this at the exact same time
      QUITLOOP
    ENDIF
    SLEEP 500
  ENDFOR
  IF NOT RETVAL THEN   ; 10 attempts
    azerror(ERRORUSER()+" has locked "+ztable,
    "Press any key to return",1000)
    ; or whatever your technique for telling your user that someting is amiss
    RETURN "Error"
  ENDIF
  z=[] ; grab the current field
  []=[]+zincrement    ; increment field
  UnLockRecord   ; free it up for others
  MOVETO zoldtable  ; back to the original table
  IF zisformview THEN
    FormKey  ; replace the form
  ENDIF
  @1,0 clear eol  ; clean up the message
  @0,0 clear eol
  RETURN z
ENDPROC


#: 60839 S15/Paradox - PAL
    25-Jan-89  20:35:46
Sb: #60753-#AutoInc Script Fixed
Fm: ALAN ZENREICH 71171,1340
To: David Lewis 70105,1242

A generic multi rowed MAXVALUE table might be appropriate, however I havent
come across any application that had to keep track of more than 255 fields
that need to be incremented (the number of fields in one record).  So, for
now, I don't know if I'd want to complicate things further.

My typeical NextNum table has between 4 and 10 fields to keep track of
various numbers.

An advantage to a multi-line approach is that in a network with extemely
heavy traffic, all the users are not trying to get at the same record at the
same time.  However it is worth considering.

Something along the line of what you are suggesting might look like:

CREATE "NextNum"
   "Field name":"A30*",
   "Number":"N",
   "Date":"D",
   "Short":"S"

 and fill it to look like

 NextNum |  Field Name   | Number     | Date     |  Short   |
     1   | Next Inv#     | 1234       |          |          |
     2   | Next Pdox Due |            | 1/1/90   |          |
     3   | Next employee#|            |          | 2134     |

I don't know if the performance change would be perceptible, but it
certainly is a viable alternate approach.  Either used with a LOCATE or
passing the record number and using a MOVETO RECORD.


#: 60888 S15/Paradox - PAL
    26-Jan-89  07:23:58
Sb: #60839-AutoInc Script Fixed
Fm: David Lewis 70105,1242
To: ALAN ZENREICH 71171,1340

Yep, that's what I had in mind, except wouldn't you want a "Table Name" column
as well, so the NextNum table could apply to several data tables.

In general, it seems like this technique would become convenient long before
it became necessary at 255 fields.  Paradox is a lot better at adding rows to
a table than columns, so it's also more maintainable.  Another bonus is that
an integrity check of the NextNum table against the actual data could be done
by a generic proc.

--David.

Hey Alan -- are we mellowing in the new year/new version?  Seems like we're
actually agreeing on something?

#: 63121 S15/Paradox - PAL
    08-Feb-89  17:27:43
Sb: AutoIncrement
Fm: Michael Ax 71560,1754
To: All

Here's the approach I use for interactive user AutoIncrement; I prefer
MemFile Clones over Tables since there's no extra viewing required and it's
quite gerneric:

; Inc_Seq#.SC  >>IncrementSequenceNumberUsingMemFile<<
; SET FIELD     SET TABLE     SET VARIABLE FILE                  ;<<<<<CUSTOM
ax.fld="Seq#"                                                    ;defaults
ax.tbl="Inc"
ax.memf="ax_lstno"
ax.msg=""

if search(sysmode(),"CoEdit")=0                                  ;test mode
   then ax.msg="Not Editing!"
else
   if table()<>ax.tbl                                            ;test file
     then ax.msg="Wrong File!"
   endif
endif

if ax.msg<>""                                                    ;error?
   then message ax.msg sleep 2000 beep
   release vars ax.msg,ax.fld,ax.tbl,ax.memf
   return ""
endif                                                            ;return
message "Incrementing.."
ax.pd=privdir()
ax.tmp=ax.pd+"savevars."                                         ;calc temp

if not isassigned(ax.lstno)                                      ;prepare
   then
     if not isfile(ax.pd+ax.memf+".sc")
        then ax.lstno=cmax(table(),ax.fld)
     else play ax.pd+ax.memf
     endif
endif                                                            ;highest

if type(ax.lstno)="A5"                                           ;nextnum
   then ax.lstno=1
else ax.lstno=ax.lstno+1
endif

moveto field ax.fld
   if not isblank([])
      then end down
   endif                                                         ; pos/ blnk
[]=ax.lstno right echo normal echo off message "Saving.."        ; insrt,right
if isfile(ax.tmp+"sc")
   then  run norefresh norestore                                 ; keep current
  "copy +ax.tmp+"sc "+ax.tmp+"max >nul"
endif                                                            ; savevars sc

savevars ax.lstno                                                ; save new one
if isfile(ax.pd+ax.memf+".sc")
   then norefresh norestore "del "+ax.pd+ax.memf+".sc"           ; delete the
endif                                                            ; latest high

run norefresh norestore "ren "+ax.tmp+"sc "+ax.memf+".sc"        ; repl w new
   if isfile(ax.tmp+"max")
      then run norefresh norestore "ren "+ax.tmp+"max *.sc"      ; restore the
   endif                                                         ; original sv
release vars ax.fld, ax.memf, ax.pd, ax.tmp                      ; release vars
; release vars ax.lstno ; X*X enable line if you're using clones ; <<<<<CUSTOM
;
; play this script using a SetKey, for example Alt-I by defining it as:
; Setkey -23 play "Inc_Seq#"
; to increment multiple Fields/Files use multiple keys/clones
;                  now PD/ Michael Ax/ Ax-Systems 718-626-0859


#: 62843 S15/Paradox - PAL
    07-Feb-89  09:43:03
Sb: INCREMENTING KEY
Fm: TODD CARY 73027,3067
To:  72561,3025

Neal-Your appraoch to self incrementing Key Fields (e.g. Invoice number)
brings up a point that I had overlooked.  Previously, I used your technique of
a Table to store the values.  I called the Table SYSPARMS since there were
several values stored in the 1 record.  However, I thought my technique was
"sloppy" and opted to use VARS in a Script and a Procedure SAVESYS() [does a
SAVEVARS and renames SAVEVARS to MYSYS.SC]---BUT I forgot about Multi-user
environments!  I cannot lock the script!!!  Now my question: is there a way to
prevent on from changing the Script while I am updating it OR is it best to
use a Table (I have some flags that I update too e.g. NOTPRINTED, ISCHANGED,
MUSTUPDATE)??? ***Todd Cary

P.S. The pitfall of using the Max value of a column is what happens if the
current maximum record is deleted by the user--assuming that deletion of
records is allowed in the application??

#: 63755 S15/Paradox - PAL
    13-Feb-89  10:10:22
Sb: INCREMENTING KEY
Fm: Neal Snitow 72561,3025
To: TODD CARY 73027,3067

Todd:

       I've found the  1 record control table to be an ideal solution for many
applications.  (In some cases, there might be one record for each division of
the company).  It works well for both single user and multi user.  It is
faster than  CMAX  when your data tables get large.

DIGRESSION: You can put lots of data integrity things into the control record
( no records, total debits, total credits, total sales, total refunds, etc
etc)  An end of day cross check of these totals between the control table and
your data tables can be a very useful auditing tool.

       IAC, auditing stuff aside, the separate control table is very
convenient for both the  'next sequential no'  issue as well as for storing
global variables like sales tax rate (if you only have 1 or 2 states),
shipping charge and any other almost-permanently-fixed number.

                                               N e a l

#: 81443 S15/Paradox - PAL
    19-May-89  15:04:43
Sb: #81271-PAL
Fm: David Randolph 76340,1012
To: chip frye (sysop) 76702,471

>> SETKEY 14 PgUp x=[] PgDn []=x+1
This SETKEY will work only if the Form has 1 regular field and is has 1 page
since PgUp will move the cursor to the LAST field of the previous page and
PgDn to the FIRST field of the next page, thereby loosing the current field
position. It will also crash if executed on an alpha field and will leave
the field blank if the field above is blank.  Here is a script that account
for these problems and a few other enhancements.
 
INIT.SC ==>  SetKey 14 Play "AutoNum"
AUTONUM.SC: ==>
If Match(FieldType(),"A..") Then Quit "Can't Increment Alpha Fields" EndIf
If AtFirst() Then
   If FieldType()="D" Then Quit "You must enter the first date"
      Else []=1 Quit
   EndIf
EndIf
If IsFormView() Then
   CtrlPgUp
   x=[]
   CtrlPgDn
Else
   Up
   x=[]
   Down
EndIf
If IsBlank(x) Then
   Quit "The Record above is Blank - It can't be incremented"
EndIf
[]=x+1
 
 
 
 




#: 62523 S15/Paradox - PAL
    05-Feb-89  13:21:24
Sb: #62249-Record - Increment
Fm: Neal Snitow 72561,3025
To: Charlie 74630,364

Charlie :

       A self incrementing number, like invoice number, can be done in several
ways.  Here are two approaches.

       If you will   * *  always  * *  be in a single user environment (risky
assumption), then take the highest value in the table and add 1 to it.  If the
table is keyed on the invoice number then (in Edit or CoEdit mode)
       End
       nextno = [Inv No] + 1
       Down
       [Inv No] = nextno

will do it for you.  If the table is not keyed on invoice no, then (in Edit or
CoEdit)
       nextno = CMax ("SalesTbl", "Inv No") + 1
       End
       Down In  a multi user situation (present or anticipated), set up a one
record control table with a nextno field.  To use the next invoice no in a new
record
       Lock the Control table (loop back and retry if someone else locked it)
       Use the Control table value for nextno
       Increment the Control table value for nextno
       Unlock the Control Table

       Remember, release locks as soon as possible - don't do any further
processing until you've freed up the control table for someone else on the
network.

                               - -   N e a l



#: 63033 S15/Paradox - PAL
    08-Feb-89  07:47:12
Sb: #62887-Record - Increment
Fm: Larry Lynn 71401,1374
To: Don Schubert 72767,1465

Don, autoincrement shouldn't be that big a problem.  Cmax is a bad idea
because of the disk reads, but storing the last number used in a table should
work fine, and doesn't require that much PAL.  Assuming single user app, such
as yours, and a table named NUMB which as one field called [Numb] which stores
the numbers, then:

   x=[Numb->numb]
   [Numb->numb]=x+1
   [Seq]=x

 The setkey macro must play this as a script, since you cannot have more than
one field assignment on a line.  In addition, there is a problem in 2.x with
field assignment to another table while in Formview, so this form is reliable
for 3.0.  Finally, the sequence is important; you must increment the stored
number BEFORE assigning a number to the current [Seq] field; otherwise, if
anything goes wrong after assigning a number but before incrementing the
stored value, you would reuse a number.  I learned this painful lesson from
experience.  This script is basically a single user version of a proc Alan
posted a while back, with no error handling.
       Larry



#: 63218 S15/Paradox - PAL
    09-Feb-89  09:28:50
Sb: #63084-Record - Increment
Fm: mark murphy 72770,3500
To: Don Schubert 72767,1465

I agree a 1 record DB file, with its 2k bite out of memory is not desirable.
However, if you are also able to put various configuration variables for your
application, other increment counters and various global variables into the
one record, it may not be too bad when compared to storing the info in
variables and arrays.

I'm thinking of doing my configuration variables this way so I can take
advantage of form-based editing and validation checking.

Mark



#: 63266 S15/Paradox - PAL
    09-Feb-89  14:35:25
Sb: #63084-Record - Increment
Fm: Larry Lynn 71401,1374
To: Don Schubert 72767,1465

Don, sorry I didn't make it clear that Numb.db has to be on the workspace -
there is no way around that; why is it a problem? In re: [seq] - I should have
made it clear that that was a dummy name for any field holding a sequential
number; if you reference the field by name, you don't need to be in it when
you hit your setkey; additionally, you won't risk accidentally overwriting
some important field.
       Larry



#: 63281 S15/Paradox - PAL
    09-Feb-89  15:26:28
Sb: #63084-Record - Increment
Fm: Dan Ehrmann 72571,3533
To: Don Schubert 72767,1465

Don:  there is no way in Paradox to assign values to tables which are not
already on the workspace in Edit or CoEdit mode.  That is simply the way
Paradox does things.

-Dan

#: 63322 S15/Paradox - PAL
    09-Feb-89  18:02:34
Sb: #63256-Record - Increment
Fm: David Lewis 70105,1242
To: Don Schubert 72767,1465

Has anybody considered putting the high-water-mark key value in a special
record of the actual data table?  I know this would have the disadvantage of
leaving a dummy record around to avoid during real processing, but it'd
eliminate the separate table.  The key of the dummy record would be the *next
available key*, so it would always be the highest record in the table.

OTOH, I'm not terribly unhappy with the prospect of an omnibus table for
global parameters, including the high-water marks of numerous tables.  Since I
frequently have such a table anyway, so it wouldn't be hard.

In this case, one way around the 1-record, many-field problem would be to have
a structure like

  FIELD         TYPE
  Param name    A5*
  N value       N
  D value       D
  Dollar value  $
  A value       A40

Each param could have a unique name and record in this table, and, depending
on its type, would store its present value in *one* of the general-purpose
data fields.  One could find the param value by a Zoom (which doesn't use the
key, right?) or a query.

Get it?  Comments?  --David.

#: 63369 S15/Paradox - PAL
    09-Feb-89  22:49:48
Sb: #63281-Record - Increment
Fm: Tim Colling 76044,645
To: Dan Ehrmann 72571,3533

Dan -

Well, there actually is, albeit a sneaky one:  put the "control" table with
the last serial# used, etc. info in a second or third page of a multitable
form as an unlinked detail table.  Messy, but effective.  <grin>

Regards, Tim

#: 63390 S15/Paradox - PAL
    10-Feb-89  06:17:25
Sb: #63374-#Record - Increment
Fm: David Lewis 70105,1242
To: Don Schubert 72767,1465

Yep, they are two different ideas.  Here in Ithaca we *make* fog and export it
to the rest of the country.  It's one of our biggest industries -all because
of Cornell, probably.  Wish we could export it *all*, however, rather than
keeping so much for home consumption, mostly in the form of overcast.

So, idea #1:  the highest key in the data table is a dummy.  Its key is really
the next available key, and the data in that dummy record is... well... dummy.
Example

   Cust num*    Cust name
   --------     --------------
     1          David Lewis
     2          Don Schubert
     3          Franz Schubert
     4          -- dummy --

To add a record, find the highest key (end of the table), insert the data
there, make a new dummy with the next highest key.  The result would be, say:

   Cust num*    Cust name
   --------     --------------
     1          David Lewis
     2          Don Schubert
     3          Franz Schubert
     4          Franz Liszt
     5          -- dummy --

Sorry, no actual Pal code today -- my code generator is resting from a tough
night with a C program.

The other idea is in the continuing message.  At least that'll cut the fog
down the middle.

--David



#: 63391 S15/Paradox - PAL
    10-Feb-89  06:17:50
Sb: #63390-Record - Increment
Fm: David Lewis 70105,1242
To: David Lewis 70105,1242 (X)

Idea #2: just a variant on the Numb.db idea.  As I understood it, Numb.db
would have a single record and a field for every high value in any other
table, the field being named and typed similarly to the data table's field for
which it served.

This is fine, and I'm not criticizing it.  I'm just suggesting as a variant to
merge it with the idea of a general-purpose table of global parameters for an
application, without getting an outrageously *wide* table.  I'm not sure why,
but that bothers me... maybe the nuisance of perusing, editing, reporting it
(though obviously, a data entry form would go a long way towards helping with
editing).

Example

  Param name     N val   $ val   D val   A val
  ---------      ------  -----   -----   -----
  sales tax        .07
  tax rate       28.00
  min bal                250.00
  start day                      1/1/80
  head man                              Otto
  high cust        123
  ...etc

In other words, each parameter uses a *record* rather than a field, and any
high values are just considered global parameters in this general sense. The
several columns are to accomodate the motley collection of types of the
general parameters;  any one parameter uses only one data column -- the one
corresponding to its type.

But the more I think about it, the more I prefer the one-wide-record method,
with a data entry form to facilitate updating -- as long as there aren't a
zillion params.

Oh well, the fog machine must have been on high last night at 1 AM.

--David.



#: 63453 S15/Paradox - PAL
    10-Feb-89  14:12:44
Sb: #63369-Record - Increment
Fm: Dan Ehrmann 72571,3533
To: Tim Colling 76044,645

Tim:  you bring up an interesting point about unlinked tables.

Yes, control tables containing special values can be placed as unlinked tables
on subsequent pages of a multi-table form.  There are a few things to be aware
of in this scenario:

Firstly, the master table will need to have at least one dummy field (A1) for
each page, so that the Paradox cursor has a place to rest when you move to
that "page".

Secondly, you cannot use WAIT TABLE or WAIT RECORD without explicitly trapping
all cursor movement keys, so that the user never moves to the second or
subsequent pages of the form with the unlinked tables.  That is real scary for
users <grin>  It means that WAIT FIELD or the DETK is really the only option.

Thirdly, UPIMAGE, DOWNIMAGE or MOVETO TABLENAME only work once you are
actually on the page containing the form you need to reference.  So the
program needs to move to the desired page first, then jump into the embedded
form.

It can be done, but it's quite complex.  We are covering the different options
and techniques in our upcoming Paradox 3 classes.

-Dan

#: 63566 S15/Paradox - PAL
    11-Feb-89  10:34:57
Sb: #63322-Record - Increment
Fm: Larry Lynn 71401,1374
To: David Lewis 70105,1242

David - it seems to me that the extra record idea just creates problem; for
one, it means the use has access to it, might delete it etc; you would
constantly have to account for it one way or another in queries, scans etc;
basically not worth the 2k savings.  A systable with this kind of info is much
more flexible - payment or donation records can be numbered after they are
batch entered and checked for accuracy, for example. Your other idea -
separate records in a systable for each number or date or whatever - is pretty
interesting.  Adding new types of info would only require a new record, and
users on a net working with different parts of the system would be less likely
to be trying to lock the same record than if all the numbers are in different
fields of the same record.  A little more overhead because of the locates, but
it can't be much.  Anyway, this is my comment.
    Larry



#: 63726 S15/Paradox - PAL
    13-Feb-89  07:21:45
Sb: #63566-Record - Increment
Fm: David Lewis 70105,1242
To: Larry Lynn 71401,1374

I agree that the extra record creates problems.  I was just suggesting it as
another tool for our bag of tricks, because (a) it might have some uses; (b)
it's good to think about things in new ways anyway... the seeds planted in our
minds might sprout later in other seasons.

Anyway, the extra record trick might be useful when the user does not have
direct access to the table, say it is only via a DETK or other interface,
which  can be programmed to leave that record intact.  Another factor in its
favor would be simplicity, especially when there are only one or two tables
needing a highest-value trick.

--David.

#: 60270 S15/Paradox - PAL
    23-Jan-89  12:13:39
Sb: #60196-auto increment
Fm: David Randolph 76340,1012
To: ALAN ZENREICH 71171,1340

Alan,

The Following will also work (for the lurkers):

If ImageType()<>"Display" Then Beep Return "" EndIf

(I used mixed case just to irritate Peter <Grin>)

  -- Dave

#: 63338 S15/Paradox - PAL
    09-Feb-89  19:59:30
Sb: pdx3.0 form bug
Fm: ALAN ZENREICH 71171,1340
To: Josh Korn 73577,2304

; I just found some errors in my original message, so this one supercedes
; the other one
Josh, how about a simple ImageC.. proc coded in pal...

Off the top of my head....

Proc azImageC(ztable,zfield,zctype)
  Private zoldfield,zoldtable,z
          ; ztable  ; name of table for imagec..
          ; zfield  ; name of field for imagec..
          ; zctype  ; "Average" "Count" "Max" "Min" "Sum"
                        ;  one proc does all
  If not ISVALID() THEN
    Return "Error"  ; could not move from the field anyway
  ENDIF
  ;- let's save our current place
  zoldfield=field()
  zoldtable=table()
  ;- now go to the field in question
  moveto ztable
  moveto field zfield
  ;-  or alternately
  ;  execute "MOVETO ["+ztable+"->"+zfield+"]"

  ;- now let's grab the value needed
  execute "z=ImageC"+zctype+"()"
  ;- now go back to where we were
  moveto zoldtable
  moveto field zoldfield
  return z
endproc

I haven't tested the code, any it might have a few rough edges, but I think
you get the idea.
Note that although ImageC.. functions require that the table is on the
workspace, whereas funtions that take table arguments (like CMax) do not
require the table to be in view.

Hope this helps....






