Hi Don,
I think it should be on Save rather than on Create for all modes of
operation. I work on networks, however conceptionally interesting is that
with web application using the CGI mechanism, I am always running DP
"locally" as a local user. That local user is actually a proxy for the web
user and can run multiple simultaneous sessions. This of course is multiuser
but not in the same way that I think are referring to running it on a
network
These are the steps I use.
Step 1 Create field PxF1
Step 2 Create field PxF2
Step 3 Create IndexN on PxF2 (ie reverse index of incrementing number)
Step 4 Create PxF2 Formula = -PxF1 /* minus even for dates */
(on ANY CHANGE)
Step 5 Create Recursive Panel link PxF3 using IndexN with no field list
Step 6 Create 2nd Recursive Panel link PxF4 also using IndexN with no field
list
Step 7 Create Formula in P1F1 when Record is SAVED
(IF PxF2=0 THEN
PxF3PxF1 /* ie thru first recursive link */
ELSE
PxF4PxF1 /* ie thru second recursive link */
ENDIF)
+ 1 /* or any other increment required */
Note: P1F1 must precede P1F2 in EDIT order
I have this all recorded in my cheat sheet and I refer to it each and every
time I create an recursive link autonumber, as I have found small deviations
in the method have cause me grief. I can't remember specifically what the
symptoms of the problems are, but the order of formulae firing is definitely
something that has caused me problems.
You can make the change to the formulae, their firing order, indexes, etc
even when the panel has records. I have found the process very resilient,
and I often make changes to the formula in Step 7, (and sometimes in Step 4)
to do interesting things like change the increment from being 1 to another
number, and to also add Alpha based incrementing , eg AA AB AC, and also to
create a final checksum on incremented numbers to make Primary keys harder
to guess.
Regards
Brian
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Don Codling
Sent: Friday, 19 November 2010 1:24 AM
To: [email protected]
Subject: Re: [Dataperf] importing from WP merge
November 18, 2010
Thanks for the suggestions, Pat and Brian.
I think you are working always with networks, are you not, Brian?
Ralph's book says with standalone computers (mine) the record number
field should be updated on create, though in networks on save. Is that
an early thought which should now be changed?
Though I've noticed it before in other comments you've made on this
subject, Brian, the need for an IF clause to be sure the number did not
already exist had not registered. Without that, if I were to export and
then import a panel, to make structural changes, my records could be
renumbered, and many of my links to records in other panels ruined. I
can see I'm going to have to be very careful until I put that guard in
all the recursive numbering I've done in the last months!
I guess I will try your suggestions in three stages. I've put the IF
clause in my formula in the index panel I was having trouble with, and
I'll soon have another batch of records to import. If that doesn't work,
and I don't hear otherwise about it, I'll try changing to update on
save. Then I'll look at making the two record number fields the first in
my edit order (I'd prefer not to do that, because if they're at the end,
it simplifies my imports from WP - I can just ignore those fields).
Thanks again. I'll let you know what happens.
Don Codling
DP 2.6y
Windows XP home, SP3
2 GBytes RAM
On 18/11/2010 8:01 AM, Brian Hancock wrote:
> Hi Don,
>
> I only use incrementing using recursive panel links and I have not had any
> problems with importing of data from a WP Merge file eg when I am making
> changes to the panel. Almost everyone of my panels uses this form of
> numbering as I always use this as a non data loaded Primary Key.
>
> Over the years I have had the odd problem of importing but I have always
> found it was something I had overlooked somewhere else.
>
> In reference to Pat's comment though the renumber on import should only be
> relevant if you have ::I fields and not the recursive link. The thought
> however got me thinking about this, and how you would initiate renumbering
> or not on an import. I think the answer is in the formula on the ID field
> which should be IF HiddenField=0 THEN etc etc and that the formula is
> triggered on the SAVE of a newly created record. Consequently if you did
not
> export the hidden field you would get renumbering, but if you do export it
> you do not. I am not sure if this helps you or not, but perhaps looking at
> when your formulae are triggered to occur might shed some light on it
>
> By the way, I am not sure if this is germane or not, probably not, but in
> terms of edit orders I ALWAYS have my recursively-linked-autonumber
Primary
> Key as my first field in the edit order, and the reverse hidden field as
the
> second.
>
> Happy hunting Don.
>
> Brian
>
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Don Codling
> Sent: Thursday, 18 November 2010 1:38 PM
> To: DataPerfect Users Discussion Group
> Subject: [Dataperf] importing from WP merge
>
> November 17, 2010
>
> I ran into a problem importing a number of records from a WP merge file
> into one of my databases. The panel uses absolute incrementation of its
> record number through a recursive panel link. A change to that from an
> autoincrementing field is the only change to this panel since I last
> imported a merge file.
>
> This time, the first record in the merge file imported, and all
> successive records were discarded as duplicates. Since there were only a
> few, I entered them manually (only one field required in each case),
> with no problems. The question is, why did DP reject the last ten
> records in the file as duplicates.
>
> I exported the affected records in that panel to a WP merge file, and
> compared the exported file to my import file. The only differences were
> two empty fields at the end of each record, followed by the record
> number and the negative record number from the autoincrementing
> recursive link.
>
> 3 indexes.
> 1: Bk #, Author title, page numbers, etc, and record number
> 2: subject, record number
> 3: Hidden negative record number for the autoincrement.
>
> In the first two indexes there would be duplicates except for the record
> number, which is supposed to increment automatically and so prevent
> duplicates.
>
> One record for you to see what I mean
> Import file
> 03951^E
> Letham^E
> R.^E
> Westminster Assembly: ... in historical context^E
> ^E
> 52^E
> 2^E
> 53^E
> Q^E
> Church of England^E
> ^R
>
>
> Export file
> 03951^E
> Letham^E
> R.^E
> Westminster Assembly: ... in historical context^E
> ^E
> 52^E
> 2^E
> 53^E
> Q^E
> Church of England^E
> ^E
> ^E
> 8484^E
> -8484^E
> ^R
>
>
> Every record had either different page numbers or different subject line
> (Here "Church of England"), and that was sufficient
>
> As I read Ralph Alvy's book, there does not seem to be anything that
> would prevent the successive records being imported from incrementing,
> but it seems that failure to do that would be the only reason for
> calling the records duplicates and rejecting them.
>
> Any help?
>
> Don Codling
> DP 2.6y
> Windows XP home, SP3
> 2 GBytes RAM
> _______________________________________________
> Dataperf mailing list
> [email protected]
> http://lists.dataperfect.nl/mailman/listinfo/dataperf
>
> _______________________________________________
> Dataperf mailing list
> [email protected]
> http://lists.dataperfect.nl/mailman/listinfo/dataperf
>
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
