Re: Array Range Check Issue

2017-07-02 Thread Justin Carr via 4D_Tech 
On 1 Jul 2017, at 12:12 am, Stephen J. Orth via 4D_Tech <4d_tech@lists.4d.com> 
wrote:
> 
> I am getting an array range check error on the following line:
> 
> If (Size of array(as_function)>=1)
> 
> This is a compiled application, so how does this type of error even exist
> for this line?
> 
> The details on the error are blank, it simply says:
> 
>Error when executing the method "Get Data Changes" at line #119
>Array Range Check Error
> 
> Anyone know what might result in this issue?

Hey Steve

Have you initialised the array somewhere in the current process before using it 
here? Having a compiler declaration isn't enough - process level arrays have an 
indeterminate initial state, so Size of array is meaningless until you have 
explicitly initialised it in your code. For this reason all of our new 
processes start with a call to Compiler_Arrays.

cheers
J
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Is there a JSON handling component for v13?

2017-07-02 Thread David Adams via 4D_Tech 
On Mon, Jul 3, 2017 at 9:29 AM, Wayne Stewart via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> Michael,
>
> Definitely go with NTK, fantastic product.
>

I haven't used Miyako's tool so I can't compare, but I include NTK in all
projects. It's a great tool and the JSON commands are essential. In fact,
they're still required in all shipping versions of 4D if you're dealing
with a lot of JSON from the outside world. So, it's not just a V13 thing so
long as 4D doesn't have a comprehensive native JSON suite.
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Is there a JSON handling component for v13?

2017-07-02 Thread Wayne Stewart via 4D_Tech 
Michael,

Definitely go with NTK, fantastic product.


Regards,

Wayne


[image: --]
Wayne Stewart
[image: http://]about.me/waynestewart



On 3 July 2017 at 09:04, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> Michael,
> The best I've found is the JSON functionality in Rob Laveaux's NTK plug in:
> http://www.pluggers.nl/product/ntk-plugin/
>
> Miyako also has a plugin on github: https://github.com/miyako/4d-
> plugin-json
>
> I've used them both. Miyako's is fully capable and if you can't justify the
> cost of NTK you can use it. I did for a couple of years on one project.
> Having done that I'll say Rob's would have been worth the money even if I'd
> only used it for the JSON commands. That's not a knock on Miyako. My
> projects are all littered with instances of Miyako's influence. It's just
> that Rob's implementation is better documented and in my opinion easier to
> work.
>
> One caveat to be aware of - there are one or two commands in both plug ins
> that share a name. Consequently you can not use both at the same time. So
> do some testing with them before committing to one or the other in your
> project.
>
> On Sun, Jul 2, 2017 at 3:18 PM, Michael Ferguson via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
>
> > I’d like the source code, but compiled is OK with good documentation.
> >
> > Thanks for any response,
> >
> > Michael Ferguson
> > MyOfficelink
> > **
> > 4D Internet Users Group (4D iNUG)
> > FAQ:  http://lists.4d.com/faqnug.html
> > Archive:  http://lists.4d.com/archives.html
> > Options: http://lists.4d.com/mailman/options/4d_tech
> > Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> > **
>
>
>
>
> --
> Kirk Brooks
> San Francisco, CA
> ===
>
> *The only thing necessary for the triumph of evil is for good men to do
> nothing.*
>
> *- Edmund Burke*
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
>
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Is there a JSON handling component for v13?

2017-07-02 Thread Kirk Brooks via 4D_Tech 
Michael,
The best I've found is the JSON functionality in Rob Laveaux's NTK plug in:
http://www.pluggers.nl/product/ntk-plugin/

Miyako also has a plugin on github: https://github.com/miyako/4d-plugin-json

I've used them both. Miyako's is fully capable and if you can't justify the
cost of NTK you can use it. I did for a couple of years on one project.
Having done that I'll say Rob's would have been worth the money even if I'd
only used it for the JSON commands. That's not a knock on Miyako. My
projects are all littered with instances of Miyako's influence. It's just
that Rob's implementation is better documented and in my opinion easier to
work.

One caveat to be aware of - there are one or two commands in both plug ins
that share a name. Consequently you can not use both at the same time. So
do some testing with them before committing to one or the other in your
project.

On Sun, Jul 2, 2017 at 3:18 PM, Michael Ferguson via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> I’d like the source code, but compiled is OK with good documentation.
>
> Thanks for any response,
>
> Michael Ferguson
> MyOfficelink
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **




-- 
Kirk Brooks
San Francisco, CA
===

*The only thing necessary for the triumph of evil is for good men to do
nothing.*

*- Edmund Burke*
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Nested transactions - most appreciated feature

2017-07-02 Thread Alan Chan via 4D_Tech 
It's our standard design to do test "In Transaction" and Trigger Level in 
trigger. We never used cascade trigger either.

Error handling in trigger is also standard in our design. We have to create 
large error code base for error interpretion in multiple language.

Alan Chan

4D iNug Technical <4d_tech@lists.4d.com> writes:
>I suppose we could have tested “In Transaction” but that’s a bit nasty because 
>it’s implicit and independent of the business logic being passed up and down 
>the call chain

>Apart from anything else, if you have any error handling running on the server 
>side at all, you need to run it in a transaction to not end up with data 
>that’s left in an ambiguous state.

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Nested transactions - most appreciated feature

2017-07-02 Thread Alan Chan via 4D_Tech 
Yes, having UI in transaction is not ideal (at least in our design) and that's 
why we never used that approach. 

Update pricing is pretty routine for us as well (in our retail module) but we 
never need nested transaction.

if no ui is involved, 

Master transaction
nested transaction 1 for task 1
nested transaction n for task n
End Master transaction

or

Transaction
update task 1
update task n
End transaction

Any difference?

Alan Chan

4D iNug Technical <4d_tech@lists.4d.com> writes:
>I have a slightly different take from Peter's - consider attempting to make
>changes in a database with many users who may or may not be 'touching' or
>accessing data involved in the chain of updating. Inventory updates are a
>classic example. Pricing can be another. Ideally these sorts of things
>would be done during off-hours but that's not always possible and a given
>update may take a few seconds to run sometimes. This is the sort of case
>where I find nested transactions really helpful. It's not possible to know
>ahead of time everything that might be touched and things may be changing
>in the meantime anyway. I like to break down a complex task into logical
>components each of which may be used in other situations so it makes sense
>to wrap each one in its own transaction and let the master transaction
>decide whether any of those subsidiary ones warrant cancelling the whole.
>
>To be honest I hadn't even considered the issue of working with components
>but Peter does a lot more of that than I do. Plus I rarely have components
>doing much of their own processing - just offering support and
>functionality to the parent db.
>
>I'll just add I think it's a bad idea to wrap any UI in a transaction. As
>Peter notes I know some folks do it and it works for them but my experience
>has never born that out.

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Nested transactions - most appreciated feature

2017-07-02 Thread Alan Chan via 4D_Tech 
Hi Peter,

I never used component and have no idea what complication would it be in 
transaction. Nonetheless, we do a lot of updates from time to time. We only use 
normal transaction and trigger even for millions of records. We normally split 
into 5,000 to
10,000 records per transaction. I don't see nested transaction is required 
except the component part that I have no knowledge at all.

Alan Chan

4D iNug Technical <4d_tech@lists.4d.com> writes:
>
>I’ve never considered transactions as a UI tool (mainly because it’s a bit of 
>a nightmare matching the scope of the opening and closing points) but I 
>acknowledge many developers successfully use them as such.
>
>Their primary use in my experience is for creating atomic database updates 
>where one of a number of validations is carried out - usually in triggers on 
>the server - during the course of the update.
>
>The code in the update can span both distinct layers in the application 
>architecture (e.g. host & components layers) as well as distinct database 
>tiers (e.g. server & client). So it has to have some way of passing an error 
>back through the call
>chain to the original update call and have it VALIDATE or CANCEL TRANSACTION.
>
>The reason for the nested transactions in that case is that the update can 
>call into some part of a modular codebase (such as a 4D component) which has 
>its own transaction handling. This used to be problematic because pre-nested 
>era, you’d have
>to support another parameter in that codebase to tell it whether transactions 
>were being handled in the caller or if it should invoke its own transaction 
>handling. (I suppose we could have tested “In Transaction” but that’s a bit 
>nasty
>because it’s implicit and independent of the business logic being passed up 
>and down the call chain).
>
>Apart from anything else, if you have any error handling running on the server 
>side at all, you need to run it in a transaction to not end up with data 
>that’s left in an ambiguous state.
>
>

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Is there a JSON handling component for v13?

2017-07-02 Thread Michael Ferguson via 4D_Tech 
I’d like the source code, but compiled is OK with good documentation.

Thanks for any response,

Michael Ferguson
MyOfficelink
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Nested transactions - most appreciated feature

2017-07-02 Thread Chip Scheide via 4D_Tech 
Transactions around a UI can be very useful.

When it is necessary to drill down many levels, it gets to be very difficult, 
or impossible to 'undo' an action when needed.
for example in my system we track animals (research).
for each animal, there are a lot of related data.
- Cages, where there are limits on the number of animals and sex of the animals
- genomics
- Familial (genealogy mating, ancestors, offspring and siblings) - this gets 
complex very quickly
- experimental results directly related to the animal
- samples taken from the animal
- experimental results from the samples.

all of these areas include an ability to 'drill down' into the data, and there 
are some 'loop backs' which have to accounted for (samples from an animal lead 
to an experiment, which can lead to the animals, which can lead to more samples 
which can lead to )

So, if a user modifies an animal record it is possible that they modify a LOT 
of data, and various levels "beneath" the animal itself, including of course 
adding or deleting records.

Trying to code a means to "back out" is/would be herculean in size.
Wrap the whole edit in a transaction, the user needs to back out? cancel and 
were done.

Animal ids are often very similar, and it happens where a user edits animal 
112113 rather then animal 113112, again as long as they realize before saving - 
backing out changes inside a transaction is simple. Cancel... Poof!  :)

So.. transactions around UIs can be very useful.

> 
> I'll just add I think it's a bad idea to wrap any UI in a transaction. As
> Peter notes I know some folks do it and it works for them but my experience
> has never born that out.

Hell is other people 
 Jean-Paul Sartre
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Nested transactions - most appreciated feature

2017-07-02 Thread Kirk Brooks via 4D_Tech 
Alan,

I have a slightly different take from Peter's - consider attempting to make
changes in a database with many users who may or may not be 'touching' or
accessing data involved in the chain of updating. Inventory updates are a
classic example. Pricing can be another. Ideally these sorts of things
would be done during off-hours but that's not always possible and a given
update may take a few seconds to run sometimes. This is the sort of case
where I find nested transactions really helpful. It's not possible to know
ahead of time everything that might be touched and things may be changing
in the meantime anyway. I like to break down a complex task into logical
components each of which may be used in other situations so it makes sense
to wrap each one in its own transaction and let the master transaction
decide whether any of those subsidiary ones warrant cancelling the whole.

To be honest I hadn't even considered the issue of working with components
but Peter does a lot more of that than I do. Plus I rarely have components
doing much of their own processing - just offering support and
functionality to the parent db.

I'll just add I think it's a bad idea to wrap any UI in a transaction. As
Peter notes I know some folks do it and it works for them but my experience
has never born that out.

On Sun, Jul 2, 2017 at 9:44 AM, Alan Chan via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> If there's no UI, why you need nested transaction? It's all on assumption
> of my understanding on nested transaction and could be wrong.
>

-- 
Kirk Brooks
San Francisco, CA
===

*The only thing necessary for the triumph of evil is for good men to do
nothing.*

*- Edmund Burke*
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Nested transactions - most appreciated feature

2017-07-02 Thread Peter Jakobsson via 4D_Tech 
On 2 Jul 2017, at 18:44, Alan Chan via 4D_Tech <4d_tech@lists.4d.com> wrote:

> If there's no UI, why you need nested transaction?


I’ve never considered transactions as a UI tool (mainly because it’s a bit of a 
nightmare matching the scope of the opening and closing points) but I 
acknowledge many developers successfully use them as such.

Their primary use in my experience is for creating atomic database updates 
where one of a number of validations is carried out - usually in triggers on 
the server - during the course of the update.

The code in the update can span both distinct layers in the application 
architecture (e.g. host & components layers) as well as distinct database tiers 
(e.g. server & client). So it has to have some way of passing an error back 
through the call chain to the original update call and have it VALIDATE or 
CANCEL TRANSACTION.

The reason for the nested transactions in that case is that the update can call 
into some part of a modular codebase (such as a 4D component) which has its own 
transaction handling. This used to be problematic because pre-nested era, you’d 
have to support another parameter in that codebase to tell it whether 
transactions were being handled in the caller or if it should invoke its own 
transaction handling. (I suppose we could have tested “In Transaction” but 
that’s a bit nasty because it’s implicit and independent of the business logic 
being passed up and down the call chain).

Apart from anything else, if you have any error handling running on the server 
side at all, you need to run it in a transaction to not end up with data that’s 
left in an ambiguous state.

Peter

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Nested transactions - most appreciated feature

2017-07-02 Thread Alan Chan via 4D_Tech 
If I understand nested transaction correctly, it's like creating an invoice 
master in a transaction (remain opened), then add invoice line item in nested 
transaction (start and end nested transaction in one go), add nth line of 
invoice items in new
nested transaction continously. Failure of one nested transaction won't affect 
other nested transaction. User simply correct the failed one and move on. At 
the end, if user cancel the invoice master (not line item) opened transaction, 
all completed
nested transactions would also be rolled back. It means as long as the invoice 
master transaction was not ended (validate or cancel), all other related 
records like inventory of those items or item master (if summary info was kept 
there) would be
locked. Other users might not be able to access them during the period.

If there's no UI, why you need nested transaction? It's all on assumption of my 
understanding on nested transaction and could be wrong.

Alan Chan

4D iNug Technical <4d_tech@lists.4d.com> writes:
>They execute in milliseconds as I never put user interfaces - or even alerts - 
>inside transactions. Just a lot of error handling and then report the error 
>after the final CANCEL TRANSACTION.

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Nested transactions - most appreciated feature

2017-07-02 Thread Peter Jakobsson via 4D_Tech 

On 2 Jul 2017, at 00:12, Alan Chan via 4D_Tech <4d_tech@lists.4d.com> wrote:

> It's a great feature if long transaction that holding up records isn't an 
> issue to your operation. Of course, make sure no one would take coffee in the 
> middle of a transaction:-)


Hi Alan

They execute in milliseconds as I never put user interfaces - or even alerts - 
inside transactions. Just a lot of error handling and then report the error 
after the final CANCEL TRANSACTION.

Peter
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**