Re: New record numbering system and CALL WORKER

2018-08-28 Thread Chip Scheide via 4D_Tech
I use longings as relational keys because it is easier to track down when the user(s) come to me as ask why some related(?) data is not where it should be. [table]ID = 1234 is a lot easier to work with then [table]ID = B83F47092A384821A9FABA5379C3CCC0 when try to track data. I don't use

Re: New record numbering system and CALL WORKER

2018-08-28 Thread Bernd Fröhlich via 4D_Tech
Kirk Brooks: > scanning back over it a key point is that all of these > contortions and workarounds to preserve a number sequence are based on the > single design decision to use an invoice (in this case) number as a key > field. Nope, the invoice number has never been a key field over here.

Re: New record numbering system and CALL WORKER

2018-08-28 Thread Benedict, Tom via 4D_Tech
Kirk Brooks writes: >I am surprised this thread has drawn so much discussion. It's good >discussion but scanning back over it a key point is that all of these >contortions and workarounds to preserve a number sequence are based on the >single design decision to use an invoice (in this case)

Re: New record numbering system and CALL WORKER

2018-08-28 Thread Kirk Brooks via 4D_Tech
I am surprised this thread has drawn so much discussion. It's good discussion but scanning back over it a key point is that all of these contortions and workarounds to preserve a number sequence are based on the single design decision to use an invoice (in this case) number as a key field. I'm not

Re: New record numbering system and CALL WORKER

2018-08-28 Thread Richard Wright via 4D_Tech
It allows you to work with related records as if they were subrecords. For example, you open an Invoice and start a transaction so that changes to line items can be rolled back if the Invoice is cancelled (something that automatically happened with subrecords). But then you want to drill down

Re: New record numbering system and CALL WORKER

2018-08-28 Thread Pat Bensky via 4D_Tech
Dave, That's fine as long as the id number isn't being used for something else ... in our case, the id numbers are used as the key field for relating data from other tables, so this needs to be assigned when the record is created ): Pat On Tue, 28 Aug 2018 at 15:32, Dave Nasralla via 4D_Tech <

Re: New record numbering system and CALL WORKER

2018-08-28 Thread Dave Nasralla via 4D_Tech
Hi Bernd, I ran into a similar situation with Proposal and Project numbers. My decision was to not give the number out until they saved the record. This prevented people from using the number elsewhere (say for purchasing, etc) without a saved record in the system. dave On Tue, Aug 28, 2018 at

Re: New record numbering system and CALL WORKER

2018-08-28 Thread Chuck Miller via 4D_Tech
Thanks. As I said I was not sure. Regards Chuck Chuck Miller Voice: (617) 739-0306 Informed Solutions, Inc. Fax: (617) 232-1064 mailto:cjmillerinformed-solutions.com Brookline, MA 02446

Re: New record numbering system and CALL WORKER

2018-08-28 Thread Pat Bensky via 4D_Tech
Good point, Bernd. I will implement that also. Pat On Tue, 28 Aug 2018 at 07:46, Bernd Fröhlich via 4D_Tech < 4d_tech@lists.4d.com> wrote: > Pat Bensky: > > > The important thing is that all record cancellations go through a > > *CancelRecord* method. > > I created a [SpareRecordNumbers] table

Re: New record numbering system and CALL WORKER

2018-08-28 Thread Bernd Fröhlich via 4D_Tech
Pat Bensky: > The important thing is that all record cancellations go through a > *CancelRecord* method. > I created a [SpareRecordNumbers] table which contains 3 fields: unique id, > table number, and spare record number > As I said, it hasn't been thoroughly tested yet. So please feel free to

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Justin Carr via 4D_Tech
On 28 Aug 2018, at 11:52 am, Chuck Miller via 4D_Tech <4d_tech@lists.4d.com> wrote: > > It does, but remember if you already have multiple transactions, you will > have to keep track and may have to suspend that many times I don't think that is true. When you SUSPEND TRANSACTION, the effective

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Chuck Miller via 4D_Tech
It does, but remember if you already have multiple transactions, you will have to keep track and may have to suspend that many times Regards Chuck Chuck Miller Voice: (617) 739-0306 Informed

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Keisuke Miyako via 4D_Tech
read access on a shared object triggers built-in Use/End use. in that sense, the speed "penalty" for access is no different to write. the speed question really boils down to what you do inside Use/End use. for example, you might do New shared object, New shared collection. you might do

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Justin Carr via 4D_Tech
On 28 Aug 2018, at 6:08 am, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> wrote: > > Hey guys - the very issue with the record counter is sketched out in the > discussion about Suspending Transactions: > > http://doc.4d.com/4Dv16/4D/16.3/Suspending-transactions.300-3652126.en.html > > > I

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Pat Bensky via 4D_Tech
Hi guys, Thanks for all your suggestions and helpful info. After considering all these options, I've come up with a simple solution that seems to work perfectly well, although it hasn't yet been tested comprehensively. The important thing is that all record cancellations go through a

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Kirk Brooks via 4D_Tech
Hey guys - the very issue with the record counter is sketched out in the discussion about Suspending Transactions: http://doc.4d.com/4Dv16/4D/16.3/Suspending-transactions.300-3652126.en.html I had missed this - it's quite a feature. On Mon, Aug 27, 2018 at 7:54 AM Keisuke Miyako via 4D_Tech <

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Tim Nevels via 4D_Tech
On Aug 27, 2018, at 2:00 PM, John DeSoi wrote: > I don't know. In some simple tests without any contention from multiple > processes, both reading and writing took 0 ms. > > I did not know Storage was slow until this thread came up. I did not see that > in the documentation, maybe only

Re: New record numbering system and CALL WORKER

2018-08-27 Thread John DeSoi via 4D_Tech
I don't know. In some simple tests without any contention from multiple processes, both reading and writing took 0 ms. I did not know Storage was slow until this thread came up. I did not see that in the documentation, maybe only something you learn about if you go to the conference. Without

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Chip Scheide via 4D_Tech
I do this too, only I use a second (related) table [Sequence_Recyled] rather then a blob. Each record in the related table holds a return value, and a relational ID. query before creating, use if found on return of a created value, a new record in the recycle table is created & populated. if

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Chip Scheide via 4D_Tech
yes :) it would simplify the code to create a new sequence value, rather then having to pass the needed info out of the current transaction/process into a new process, and then transfer it back. I'll keep this in mind for when I finally get to v16+ :) On Mon, 27 Aug 2018 14:53:13 +,

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Keith Culotta via 4D_Tech
Does the speed penalty apply to reading values from Storage, or just to writing values to Storage? Thanks, Keith - CDI > On Aug 26, 2018, at 8:57 AM, John DeSoi via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Storage is the best option for interprocess communications if you want to use >

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Keisuke Miyako via 4D_Tech
transactions can be paused since v16 would that help? http://doc.4d.com/4Dv16/4D/16.3/SUSPEND-TRANSACTION.301-3652123.en.html > 2018/08/27 23:46、Chip Scheide via 4D_Tech <4d_tech@lists.4d.com>のメール: > working from inside a transaction requires (as far as I can figure out) > stepping outside the

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Chip Scheide via 4D_Tech
there is the catch :) working from inside a transaction requires (as far as I can figure out) stepping outside the transaction process and generating the value(s) then passing the value(s) back into the transaction. Returning requires the same thing-in reverse. Chip On Sat, 25 Aug 2018

Re: New record numbering system and CALL WORKER

2018-08-27 Thread Jody Bevan via 4D_Tech
Chuck: That is exactly what we do for our code. Has served us well for all our sites. We can have 200+ current users on the system, importing records from labs (thus needing lots of counters quickly), and never noticed a problem with the system. For those counters we do not wanted to have one

Re: New record numbering system and CALL WORKER

2018-08-26 Thread Chuck Miller via 4D_Tech
OK i have done this many times with a table. You have multiple records in the table, one for each id you need. I usually make that records key name ([table]field). If you have to keep track of released numbers, you can add a blob field. I would not be adding object fields as you can not access

Re: New record numbering system and CALL WORKER

2018-08-26 Thread Tim Nevels via 4D_Tech
On Aug 26, 2018, at 2:00 PM, Keisuke Miyako wrote: > I totally agree with Christian, in fact, > the point (slow, should be avoided if possible) was right there in the Summit > keynote. > > on the point of "slow" > of course it is a relative thing and perhaps not a big deal depending on the >

Re: New record numbering system and CALL WORKER

2018-08-26 Thread John DeSoi via 4D_Tech
Storage is the best option for interprocess communications if you want to use preemptive processes. I have not done any real benchmarking but I have not noticed that anything seems slow. By setting up return values on a per-process basis you can avoid locking contention on storage. For

Re: New record numbering system and CALL WORKER

2018-08-26 Thread Keisuke Miyako via 4D_Tech
I totally agree with Christian, in fact, the point (slow, should be avoided if possible) was right there in the Summit keynote. on the point of "slow" of course it is a relative thing and perhaps not a big deal depending on the context, but you only have to run code with Storage and the speed

Re: New record numbering system and CALL WORKER

2018-08-26 Thread Tim Nevels via 4D_Tech
Humm... interesting comment. Why do you say Storage is slower and can produce deadlocks? Tell us why you believe this. Was my example an example of “not well programmed”? Be honest. Give me real, solid, constructive criticism. This is a forum for exchanging ideas and learning. I’ve been

Re: New record numbering system and CALL WORKER

2018-08-26 Thread Christian Sakowski via 4D_Tech
> But lets explore other possibilities. Hopefully not. You should avoid Storage where you can. They are slower and can produce (if not well programmed) dead locks. -- Grüße/Regards, [heubach-media] | Christian Sakowski christian.sakow...@heubach-media.de iChat/AIM: SakowskiF Tel: +49/(0)40/52

Re: New record numbering system and CALL WORKER

2018-08-25 Thread John DeSoi via 4D_Tech
Hi Pat, Set the method property to "Execute on Server". This shared object/collection could also have a collection of numbers that need to be reused if you require that there are no missing numbers in your sequence. Of course, you'll have to get the database involved at some level to handle

Re: New record numbering system and CALL WORKER

2018-08-25 Thread Tim Nevels via 4D_Tech
On Aug 25, 2018, at 4:33 PM, Christian Sakowski wrote: > i mainly use Storage as „constants“. I store global attributes and user > specific options and access rights. Those are in fact mostly read only. Hi Christian, And that is a great use of “Storage”. I’ll be doing the same thing in new

Re: New record numbering system and CALL WORKER

2018-08-25 Thread Christian Sakowski via 4D_Tech
Tim, i mainly use Storage as „constants“. I store global attributes and user specific options and access rights. Those are in fact mostly read only. -- Grüße/Regards, [heubach-media] | Christian Sakowski christian.sakow...@heubach-media.de iChat/AIM: SakowskiF Tel: +49/(0)40/52 10 59-23 > Am

Re: New record numbering system and CALL WORKER

2018-08-25 Thread Tim Nevels via 4D_Tech
On Aug 25, 2018, at 2:25 PM, Christian Sakowski wrote: > This is not necessary. For just reading you don’t need to use „use“. > For generating sequence numbers, you have to use „auto increment“. Nothing > else. > For invoice numbers, you now can save the number to the database within >

Re: New record numbering system and CALL WORKER

2018-08-25 Thread Christian Sakowski via 4D_Tech
> Use (Storage) > [MyNextNumber]NextNumber:=Storage.myNextNumber > End use This is not necessary. For just reading you don’t need to use „use“. For generating sequence numbers, you have to use „auto increment“. Nothing else. For invoice numbers, you now can save the number to the database

Re: New record numbering system and CALL WORKER

2018-08-25 Thread Tim Nevels via 4D_Tech
On Aug 25, 2018, at 10:33 AM, Pat Bensky wrote: > Thanks John. > But how would that work in a multi-user setting? Whatever method is used > for assigning the new numbers, it must run on the server, otherwise we're > back to the problem of using semaphores, checking record locking, etc. > Also I

Re: New record numbering system and CALL WORKER

2018-08-25 Thread Kirk Brooks via 4D_Tech
Pat, On Sat, Aug 25, 2018 at 8:25 AM Pat Bensky via 4D_Tech <4d_tech@lists.4d.com> wrote: > What you say makes sense, but the record number as key field is so integral > to the way the program works, it would be a nightmare to try and change it > Understood. But this approach still works, you

Re: New record numbering system and CALL WORKER

2018-08-25 Thread Pat Bensky via 4D_Tech
Hi Kirk, What you say makes sense, but the record number as key field is so integral to the way the program works, it would be a nightmare to try and change it :) If I was starting a project from scratch, that would be a different story. Pat On Sat, 25 Aug 2018 at 16:20, Kirk Brooks via 4D_Tech

Re: New record numbering system and CALL WORKER

2018-08-25 Thread Pat Bensky via 4D_Tech
Thanks John. But how would that work in a multi-user setting? Whatever method is used for assigning the new numbers, it must run on the server, otherwise we're back to the problem of using semaphores, checking record locking, etc. Also I should point out that there could be a large number of

Re: New record numbering system and CALL WORKER

2018-08-25 Thread Kirk Brooks via 4D_Tech
Pat, A couple of thoughts since it sounds like you're refactoring your code (all pseudo code, v17): 1) don't use this number as a key field. 2) The counter record: [COUNTER] ID name - optional but a good idea _data - object field: { nextNumber: 0, returned: []} 3) Counter_get_next(text) ->

Re: New record numbering system and CALL WORKER

2018-08-25 Thread John DeSoi via 4D_Tech
> On Aug 25, 2018, at 9:10 AM, Pat Bensky via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > As I see it, we'll need to call a worker, which calls the worker that > assigns the record number. > The first worker has to wait until the second one has created the new > number. > Then the original

New record numbering system and CALL WORKER

2018-08-25 Thread Pat Bensky via 4D_Tech
Using v17 ... I'm looking at ways to update our ancient record numbering system, and I think I should be able to do it efficiently with CALL WORKER, but having a bit of trouble getting my head around it. The record numbers are like invoice numbers: each must be unique, and we don't want to have