Hi Jacques, I am not sure the /SID switch would be of much benefit, it is only used to pull external data into DP from the command line.
But Ralph Alvy's Recursive Link will certainly do the trick, and you will be able to run DP at far greater speeds with newer hardware. It is far better than DP's :IN incrementing numbers as the value is not stored in the STR file, so you can do minor updates to the STR without taking the database offline (conditions apply). You can also create your own incrementing format with some clever programming e.g., AA, AB, AC ...BA,BB... or similar which can be handy if you have say multiple invoicing locations and wanted to create Invoice Numbering sequences like Axxxx for one site and Bxxxx for another site and to be able to consolidate them without duplicates. Also keep in mind when upgrading machines that if you are using a 64-bit Windows as the underlying OS, then you should acquaint yourself with vDOS. Good luck Brian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rich Bragonje Sent: Tuesday, 8 April 2014 12:07 AM To: [email protected]; [email protected] Subject: Re: [Dataperf] Running into problems Hi Jacques, You might be able to use the /SID - Session ID switch, that Brian Hancock mentioned in his post of 30 Mar 2014 08:18:29 +1100. I haven't used this feature, but it sounds like what you are trying to do. Rich At 08:00 AM 4/7/2014, you wrote: >Hi All, > >It was from 1986 thru 1993 that I programmed a comprehensive >application in DataPerfect (appr. 80.000 lines of code, comprising >30 interrelated panels) which administered the complete workflow for an >advertising photography and or movie production studio. A last set of >modules that was added to the application, consisted of an automated >bookkeeping add-on, that would function also as a stand-alone. > >At that time, believing computers would not run any faster than they >did, I programmed each relative link thus, that to obtain an absolute >unique record in the indexes, it had to generate a hidden date and >timestamp at the creation of each new record. When closing the >book-year at years end, through the printer level, the data would be >changed as to block the original data input. This panel replicated the >original (separate) data-input panel and could also be used to recover >old data whenever something would corrupt the financial files. > >Until now the application has continued to work flawlessly. But with >the speed of computers these days, the system does not work any more >when reconstructing the records, because within one second many records >can be generated carrying the same time stamp, thus corrupting the >index(es) for those newly generated records. >Reprogramming this time stamp to a <FORMAT:~GZZZZZZZZZ9::IH~> is not a >good option, given that over time millions of numbers must be >generated; all being unique! Thus I kept one old computer with an AMD >386 40MHz. processor. Having that system processor running at half >speed, would be sufficient to keep generating records at less than one >record a second, as to comply with each record keeping a unique value >in the indexes. > >With this sole computer becoming older and thus more unreliable, >Something must be done to keep the system up and running. I have tried >to find an answer in forcefully slowing the clock speed of present day >processors, but nobody has an answer to that so far. >Another option would be a math formula (applicable to DataPerfect DPIMP >compilation) that could generate unique coding (either numbers, or a >combination of numbers and letters). > >Does anyone have a suggestion? > >Jacques _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/cgi-bin/mailman/listinfo/dataperf _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/cgi-bin/mailman/listinfo/dataperf
