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 relati
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.
Gre
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) number
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
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 to
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 <
4d_
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 12
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 U
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 wh
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
>
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
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 Soluti
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 collection
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 had
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
*CancelRecord
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 <
4
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 somethi
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 s
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 d
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 +, Keis
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
> pree
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 t
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 08:20:
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 g
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 u
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
> co
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 example
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 di
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 wrong
> 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 10
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
s
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
d
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
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
> transac
> 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 within
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 sh
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 ju
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 <4
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 tables
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) ->
> 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 metho
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
42 matches
Mail list logo