EpiViewNotification

Yahoo Archive
1
Glad it worked out... Don't question why... Just move on. :)
Rob Brown

Michael McWilliams <mmcwilliams22@...> wrote:
I now have it working using the EpiViewNotification. I have no
explanation but for some reason I could not even get an OnClick to
work in this customization. No compile errors though. I have about
200 lines of code so maybe something else was causing a problem.

I started from scratch, pasted my code in from the other one. Then
added my controls & it works, go figure..
--- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...>
wrote:
>
> Hi Rob,
>
> No not on the payroll
>
> I did not say that the EpiViewNotification was the
best
> place to put this kind of code, as some things do not fire a
change like
> you mentioned and others fire several times,
>
> often you will have an OnchangeOf event that you
can
> catch Via BPM or an after / before adapter call, or catch the
column
> changing event.
>
> It all depends on the situation, like many of these
> things.
>
> If Michael could provide an example we could look
at the
> different approaches one could take...
>
>
>
> Regards,
>
> Stephen Edginton (Beng)
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
Behalf
> Of Robert Brown
> Sent: Thursday, December 13, 2007 8:44 PM
> To: vantage@yahoogroups.com
> Subject: RE: [Vantage] EpiViewNotification
>
>
>
> Thanks Stephen.
>
> Fascinating (really). You sound like you're on the payroll at
Epicor.
>
> Optomistic record locking is one of those 'sounds good' ideas (to
make
> programming easier and the resulting UI responsiveness better)
that has
> turned out to be less than stellar in practice.
>
> Hopefully we will see the last of it within the next few years.
>
> None of your excellent explanations of VB.NET client/server
interaction
> gets at the problem:
>
> EpiViewNotifications more often than not DO NOT WORK - even in
cases
> where I can see (via odbc) that the table data has indeed been
updated.
>
> If you have some definitive insight as to why, I'd truly love to
hear
> it.
>
> If/until EpiViewNotifications prove to work reliably, I found it
easier
> not to waste time attempting to use them.
>
> Other event triggers DO work 'as advertised' on a consistent basis
so it
> is a more efficient use of programming time simply to use them if
> they'll get the job done. That was my advice to Micheal.
>
> Thanks for the info.
>
> Rob Brown
>
> Stephen Edginton <stephene@...
> <mailto:stephene%40dotnetit.co.uk> > wrote:
> Rob,
>
> Just to clarify some points.
>
> The UI layer is all based on dataviews. This dataview is
> the view of a particular dataTable. This dataTable is one of many
in a
> data set.
>
> These objects are all in memory.
>
> The process goes as follows - Client connects to
> appservers - requests data, appservers querires database - returns
a
> dataset - a copy of the data.
>
> The client then receives this dataset and the form
> controls that are bound to a specific EpiDataView (encapsulated
> dataview) are notified via the EpiViewNotification process.
>
> At this point there is no record locking going on.
> Anther user could open the same form - pull up the same
information make
> a save, then if you go to save again you get the
>
> "this record has been modified by another user"
>
> Hence it uses optimistic locking.
>
> If you need to change the value of a bound control - you
> do not change the control itself
>
> i.e. a checkbox on the screen, you would not change the
> checked property
>
> instead you would change the value in the bound
> dataview.
>
> Hope this clears up some questions.
>
> Regards,
>
> Stephen
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> [mailto:vantage@yahoogroups.com <mailto:vantage%
40yahoogroups.com> ] On
> Behalf
> Of Robert Brown
> Sent: Thursday, December 13, 2007 2:31 PM
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: Re: [Vantage] EpiViewNotification
>
> I've found the same (making EpiViewNotification a rather useless
event
> trigger).
>
> In some customization applications, you can replace the standard
control
> with a custom control and use the custom control to trigger what
ever it
> is you are trying to do.
>
> I suspect controls tied to a view do so through a (poorly designed)
> control-db layer that sustains a record lock condition that
effectively
> short circuits the EpiViewNotification.
>
> My understanding is that both Progress and SQL Server support field
> (versus entire record) locking during I/O actions. I hope Epicor
> (perhaps in v9) does a rewrite of the layer so it results in less
> contention for records during I/O actions. Going to field level
locking
> (for appropriate actions) would improve perceived user app
performance
> considerably.
>
> Rob Brown
>
> Michael McWilliams <mmcwilliams22@...
> <mailto:mmcwilliams22%40yahoo.com>
> <mailto:mmcwilliams22%40yahoo.com> > wrote:
> Has anyone else used this and had issues? If I have a control that
> is tied to a DataView I cannot modify it using code after the
> EpiViewNotification. But if a have a control not tied to the
DataView
> it will work. I though that this Event happened after the Table
was
> pulled in & the DataSet was ready to be modified.
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>






---------------------------------
Never miss a thing. Make Yahoo your homepage.

[Non-text portions of this message have been removed]
2
Has anyone else used this and had issues? If I have a control that
is tied to a DataView I cannot modify it using code after the
EpiViewNotification. But if a have a control not tied to the DataView
it will work. I though that this Event happened after the Table was
pulled in & the DataSet was ready to be modified.
3
I've found the same (making EpiViewNotification a rather useless event trigger).

In some customization applications, you can replace the standard control with a custom control and use the custom control to trigger what ever it is you are trying to do.

I suspect controls tied to a view do so through a (poorly designed) control-db layer that sustains a record lock condition that effectively short circuits the EpiViewNotification.

My understanding is that both Progress and SQL Server support field (versus entire record) locking during I/O actions. I hope Epicor (perhaps in v9) does a rewrite of the layer so it results in less contention for records during I/O actions. Going to field level locking (for appropriate actions) would improve perceived user app performance considerably.

Rob Brown

Michael McWilliams <mmcwilliams22@...> wrote:
Has anyone else used this and had issues? If I have a control that
is tied to a DataView I cannot modify it using code after the
EpiViewNotification. But if a have a control not tied to the DataView
it will work. I though that this Event happened after the Table was
pulled in & the DataSet was ready to be modified.






---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

[Non-text portions of this message have been removed]
4
Rob,

Just to clarify some points.



The UI layer is all based on dataviews. This dataview is
the view of a particular dataTable. This dataTable is one of many in a
data set.

These objects are all in memory.

The process goes as follows - Client connects to
appservers - requests data, appservers querires database - returns a
dataset - a copy of the data.



The client then receives this dataset and the form
controls that are bound to a specific EpiDataView (encapsulated
dataview) are notified via the EpiViewNotification process.



At this point there is no record locking going on.
Anther user could open the same form - pull up the same information make
a save, then if you go to save again you get the

"this record has been modified by another user"

Hence it uses optimistic locking.



If you need to change the value of a bound control - you
do not change the control itself

i.e. a checkbox on the screen, you would not change the
checked property

instead you would change the value in the bound
dataview.



Hope this clears up some questions.



Regards,

Stephen



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Robert Brown
Sent: Thursday, December 13, 2007 2:31 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] EpiViewNotification



I've found the same (making EpiViewNotification a rather useless event
trigger).

In some customization applications, you can replace the standard control
with a custom control and use the custom control to trigger what ever it
is you are trying to do.

I suspect controls tied to a view do so through a (poorly designed)
control-db layer that sustains a record lock condition that effectively
short circuits the EpiViewNotification.

My understanding is that both Progress and SQL Server support field
(versus entire record) locking during I/O actions. I hope Epicor
(perhaps in v9) does a rewrite of the layer so it results in less
contention for records during I/O actions. Going to field level locking
(for appropriate actions) would improve perceived user app performance
considerably.

Rob Brown

Michael McWilliams <mmcwilliams22@...
<mailto:mmcwilliams22%40yahoo.com> > wrote:
Has anyone else used this and had issues? If I have a control that
is tied to a DataView I cannot modify it using code after the
EpiViewNotification. But if a have a control not tied to the DataView
it will work. I though that this Event happened after the Table was
pulled in & the DataSet was ready to be modified.

---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
it now.

[Non-text portions of this message have been removed]



[Non-text portions of this message have been removed]
5
Some additional info:
Wether I change the Value of the control or the value in the
dataview it still does not work. I have tried nedEpiCustom1.Value =
variable
and
StockDtl.dataView(StockDtl.Row)("Number01") = variable

From what you are saying the second should work, correct?

--- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...>
wrote:
>
> Rob,
>
> Just to clarify some points.
>
>
>
> The UI layer is all based on dataviews. This
dataview is
> the view of a particular dataTable. This dataTable is one of many
in a
> data set.
>
> These objects are all in memory.
>
> The process goes as follows - Client connects to
> appservers - requests data, appservers querires database -
returns a
> dataset - a copy of the data.
>
>
>
> The client then receives this dataset and the form
> controls that are bound to a specific EpiDataView (encapsulated
> dataview) are notified via the EpiViewNotification process.
>
>
>
> At this point there is no record locking going on.
> Anther user could open the same form - pull up the same
information make
> a save, then if you go to save again you get the
>
> "this record has been modified by another user"
>
> Hence it uses optimistic locking.
>
>
>
> If you need to change the value of a bound
control - you
> do not change the control itself
>
> i.e. a checkbox on the screen, you would not
change the
> checked property
>
> instead you would change the value in the bound
> dataview.
>
>
>
> Hope this clears up some questions.
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
Behalf
> Of Robert Brown
> Sent: Thursday, December 13, 2007 2:31 PM
> To: vantage@yahoogroups.com
> Subject: Re: [Vantage] EpiViewNotification
>
>
>
> I've found the same (making EpiViewNotification a rather useless
event
> trigger).
>
> In some customization applications, you can replace the standard
control
> with a custom control and use the custom control to trigger what
ever it
> is you are trying to do.
>
> I suspect controls tied to a view do so through a (poorly designed)
> control-db layer that sustains a record lock condition that
effectively
> short circuits the EpiViewNotification.
>
> My understanding is that both Progress and SQL Server support field
> (versus entire record) locking during I/O actions. I hope Epicor
> (perhaps in v9) does a rewrite of the layer so it results in less
> contention for records during I/O actions. Going to field level
locking
> (for appropriate actions) would improve perceived user app
performance
> considerably.
>
> Rob Brown
>
> Michael McWilliams <mmcwilliams22@...
> <mailto:mmcwilliams22%40yahoo.com> > wrote:
> Has anyone else used this and had issues? If I have a control that
> is tied to a DataView I cannot modify it using code after the
> EpiViewNotification. But if a have a control not tied to the
DataView
> it will work. I though that this Event happened after the Table
was
> pulled in & the DataSet was ready to be modified.
>
> ---------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
Try
> it now.
>
> [Non-text portions of this message have been removed]
>
>
>
> [Non-text portions of this message have been removed]
>
6
And When you change it in the dataview do you create a notification to
inform the screen things have changed?



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Michael McWilliams
Sent: Thursday, December 13, 2007 2:55 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: EpiViewNotification



Some additional info:
Wether I change the Value of the control or the value in the
dataview it still does not work. I have tried nedEpiCustom1.Value =
variable
and
StockDtl.dataView(StockDtl.Row)("Number01") = variable

From what you are saying the second should work, correct?

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Stephen Edginton" <stephene@...>
wrote:
>
> Rob,
>
> Just to clarify some points.
>
>
>
> The UI layer is all based on dataviews. This
dataview is
> the view of a particular dataTable. This dataTable is one of many
in a
> data set.
>
> These objects are all in memory.
>
> The process goes as follows - Client connects to
> appservers - requests data, appservers querires database -
returns a
> dataset - a copy of the data.
>
>
>
> The client then receives this dataset and the form
> controls that are bound to a specific EpiDataView (encapsulated
> dataview) are notified via the EpiViewNotification process.
>
>
>
> At this point there is no record locking going on.
> Anther user could open the same form - pull up the same
information make
> a save, then if you go to save again you get the
>
> "this record has been modified by another user"
>
> Hence it uses optimistic locking.
>
>
>
> If you need to change the value of a bound
control - you
> do not change the control itself
>
> i.e. a checkbox on the screen, you would not
change the
> checked property
>
> instead you would change the value in the bound
> dataview.
>
>
>
> Hope this clears up some questions.
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf
> Of Robert Brown
> Sent: Thursday, December 13, 2007 2:31 PM
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: Re: [Vantage] EpiViewNotification
>
>
>
> I've found the same (making EpiViewNotification a rather useless
event
> trigger).
>
> In some customization applications, you can replace the standard
control
> with a custom control and use the custom control to trigger what
ever it
> is you are trying to do.
>
> I suspect controls tied to a view do so through a (poorly designed)
> control-db layer that sustains a record lock condition that
effectively
> short circuits the EpiViewNotification.
>
> My understanding is that both Progress and SQL Server support field
> (versus entire record) locking during I/O actions. I hope Epicor
> (perhaps in v9) does a rewrite of the layer so it results in less
> contention for records during I/O actions. Going to field level
locking
> (for appropriate actions) would improve perceived user app
performance
> considerably.
>
> Rob Brown
>
> Michael McWilliams <mmcwilliams22@...
> <mailto:mmcwilliams22%40yahoo.com> > wrote:
> Has anyone else used this and had issues? If I have a control that
> is tied to a DataView I cannot modify it using code after the
> EpiViewNotification. But if a have a control not tied to the
DataView
> it will work. I though that this Event happened after the Table
was
> pulled in & the DataSet was ready to be modified.
>
> ---------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
Try
> it now.
>
> [Non-text portions of this message have been removed]
>
>
>
> [Non-text portions of this message have been removed]
>



[Non-text portions of this message have been removed]
7
No. Do I then call the EpiViewNotification again?
--- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...>
wrote:
>
> And When you change it in the dataview do you create a
notification to
> inform the screen things have changed?
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
Behalf
> Of Michael McWilliams
> Sent: Thursday, December 13, 2007 2:55 PM
> To: vantage@yahoogroups.com
> Subject: [Vantage] Re: EpiViewNotification
>
>
>
> Some additional info:
> Wether I change the Value of the control or the value in the
> dataview it still does not work. I have tried nedEpiCustom1.Value
=
> variable
> and
> StockDtl.dataView(StockDtl.Row)("Number01") = variable
>
> From what you are saying the second should work, correct?
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> "Stephen Edginton" <stephene@>
> wrote:
> >
> > Rob,
> >
> > Just to clarify some points.
> >
> >
> >
> > The UI layer is all based on dataviews. This
> dataview is
> > the view of a particular dataTable. This dataTable is one of
many
> in a
> > data set.
> >
> > These objects are all in memory.
> >
> > The process goes as follows - Client connects to
> > appservers - requests data, appservers querires database -
> returns a
> > dataset - a copy of the data.
> >
> >
> >
> > The client then receives this dataset and the form
> > controls that are bound to a specific EpiDataView (encapsulated
> > dataview) are notified via the EpiViewNotification process.
> >
> >
> >
> > At this point there is no record locking going on.
> > Anther user could open the same form - pull up the same
> information make
> > a save, then if you go to save again you get the
> >
> > "this record has been modified by another user"
> >
> > Hence it uses optimistic locking.
> >
> >
> >
> > If you need to change the value of a bound
> control - you
> > do not change the control itself
> >
> > i.e. a checkbox on the screen, you would not
> change the
> > checked property
> >
> > instead you would change the value in the bound
> > dataview.
> >
> >
> >
> > Hope this clears up some questions.
> >
> >
> >
> > Regards,
> >
> > Stephen
> >
> >
> >
> > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> [mailto:vantage@yahoogroups.com <mailto:vantage%
40yahoogroups.com> ] On
> Behalf
> > Of Robert Brown
> > Sent: Thursday, December 13, 2007 2:31 PM
> > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > Subject: Re: [Vantage] EpiViewNotification
> >
> >
> >
> > I've found the same (making EpiViewNotification a rather useless
> event
> > trigger).
> >
> > In some customization applications, you can replace the standard
> control
> > with a custom control and use the custom control to trigger what
> ever it
> > is you are trying to do.
> >
> > I suspect controls tied to a view do so through a (poorly
designed)
> > control-db layer that sustains a record lock condition that
> effectively
> > short circuits the EpiViewNotification.
> >
> > My understanding is that both Progress and SQL Server support
field
> > (versus entire record) locking during I/O actions. I hope Epicor
> > (perhaps in v9) does a rewrite of the layer so it results in less
> > contention for records during I/O actions. Going to field level
> locking
> > (for appropriate actions) would improve perceived user app
> performance
> > considerably.
> >
> > Rob Brown
> >
> > Michael McWilliams <mmcwilliams22@
> > <mailto:mmcwilliams22%40yahoo.com> > wrote:
> > Has anyone else used this and had issues? If I have a control
that
> > is tied to a DataView I cannot modify it using code after the
> > EpiViewNotification. But if a have a control not tied to the
> DataView
> > it will work. I though that this Event happened after the Table
> was
> > pulled in & the DataSet was ready to be modified.
> >
> > ---------------------------------
> > Be a better friend, newshound, and know-it-all with Yahoo!
Mobile.
> Try
> > it now.
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
> [Non-text portions of this message have been removed]
>
8
StockDtl.dataView(StockDtl.Row)("Number01") = variable
StockDtl.Notify( New EpiNotifyArgs( [FormName], StockDtl.Row,
StockDtl.Column))

bw

--- In vantage@yahoogroups.com, "Michael McWilliams"
<mmcwilliams22@...> wrote:
>
> No. Do I then call the EpiViewNotification again?
> --- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@>
> wrote:
> >
> > And When you change it in the dataview do you create a
> notification to
> > inform the screen things have changed?
> >
> >
> >
> > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> Behalf
> > Of Michael McWilliams
> > Sent: Thursday, December 13, 2007 2:55 PM
> > To: vantage@yahoogroups.com
> > Subject: [Vantage] Re: EpiViewNotification
> >
> >
> >
> > Some additional info:
> > Wether I change the Value of the control or the value in the
> > dataview it still does not work. I have tried nedEpiCustom1.Value
> =
> > variable
> > and
> > StockDtl.dataView(StockDtl.Row)("Number01") = variable
> >
> > From what you are saying the second should work, correct?
> >
> > --- In vantage@yahoogroups.com <mailto:vantage%
40yahoogroups.com> ,
> > "Stephen Edginton" <stephene@>
> > wrote:
> > >
> > > Rob,
> > >
> > > Just to clarify some points.
> > >
> > >
> > >
> > > The UI layer is all based on dataviews. This
> > dataview is
> > > the view of a particular dataTable. This dataTable is one of
> many
> > in a
> > > data set.
> > >
> > > These objects are all in memory.
> > >
> > > The process goes as follows - Client connects to
> > > appservers - requests data, appservers querires database -
> > returns a
> > > dataset - a copy of the data.
> > >
> > >
> > >
> > > The client then receives this dataset and the form
> > > controls that are bound to a specific EpiDataView (encapsulated
> > > dataview) are notified via the EpiViewNotification process.
> > >
> > >
> > >
> > > At this point there is no record locking going on.
> > > Anther user could open the same form - pull up the same
> > information make
> > > a save, then if you go to save again you get the
> > >
> > > "this record has been modified by another user"
> > >
> > > Hence it uses optimistic locking.
> > >
> > >
> > >
> > > If you need to change the value of a bound
> > control - you
> > > do not change the control itself
> > >
> > > i.e. a checkbox on the screen, you would not
> > change the
> > > checked property
> > >
> > > instead you would change the value in the bound
> > > dataview.
> > >
> > >
> > >
> > > Hope this clears up some questions.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Stephen
> > >
> > >
> > >
> > > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > [mailto:vantage@yahoogroups.com <mailto:vantage%
> 40yahoogroups.com> ] On
> > Behalf
> > > Of Robert Brown
> > > Sent: Thursday, December 13, 2007 2:31 PM
> > > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > > Subject: Re: [Vantage] EpiViewNotification
> > >
> > >
> > >
> > > I've found the same (making EpiViewNotification a rather
useless
> > event
> > > trigger).
> > >
> > > In some customization applications, you can replace the
standard
> > control
> > > with a custom control and use the custom control to trigger
what
> > ever it
> > > is you are trying to do.
> > >
> > > I suspect controls tied to a view do so through a (poorly
> designed)
> > > control-db layer that sustains a record lock condition that
> > effectively
> > > short circuits the EpiViewNotification.
> > >
> > > My understanding is that both Progress and SQL Server support
> field
> > > (versus entire record) locking during I/O actions. I hope Epicor
> > > (perhaps in v9) does a rewrite of the layer so it results in
less
> > > contention for records during I/O actions. Going to field level
> > locking
> > > (for appropriate actions) would improve perceived user app
> > performance
> > > considerably.
> > >
> > > Rob Brown
> > >
> > > Michael McWilliams <mmcwilliams22@
> > > <mailto:mmcwilliams22%40yahoo.com> > wrote:
> > > Has anyone else used this and had issues? If I have a control
> that
> > > is tied to a DataView I cannot modify it using code after the
> > > EpiViewNotification. But if a have a control not tied to the
> > DataView
> > > it will work. I though that this Event happened after the Table
> > was
> > > pulled in & the DataSet was ready to be modified.
> > >
> > > ---------------------------------
> > > Be a better friend, newshound, and know-it-all with Yahoo!
> Mobile.
> > Try
> > > it now.
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
9
Thanks Stephen.

Fascinating (really). You sound like you're on the payroll at Epicor.

Optomistic record locking is one of those 'sounds good' ideas (to make programming easier and the resulting UI responsiveness better) that has turned out to be less than stellar in practice.

Hopefully we will see the last of it within the next few years.

None of your excellent explanations of VB.NET client/server interaction gets at the problem:

EpiViewNotifications more often than not DO NOT WORK - even in cases where I can see (via odbc) that the table data has indeed been updated.

If you have some definitive insight as to why, I'd truly love to hear it.

If/until EpiViewNotifications prove to work reliably, I found it easier not to waste time attempting to use them.

Other event triggers DO work 'as advertised' on a consistent basis so it is a more efficient use of programming time simply to use them if they'll get the job done. That was my advice to Micheal.

Thanks for the info.

Rob Brown








Stephen Edginton <stephene@...> wrote:
Rob,

Just to clarify some points.

The UI layer is all based on dataviews. This dataview is
the view of a particular dataTable. This dataTable is one of many in a
data set.

These objects are all in memory.

The process goes as follows - Client connects to
appservers - requests data, appservers querires database - returns a
dataset - a copy of the data.

The client then receives this dataset and the form
controls that are bound to a specific EpiDataView (encapsulated
dataview) are notified via the EpiViewNotification process.

At this point there is no record locking going on.
Anther user could open the same form - pull up the same information make
a save, then if you go to save again you get the

"this record has been modified by another user"

Hence it uses optimistic locking.

If you need to change the value of a bound control - you
do not change the control itself

i.e. a checkbox on the screen, you would not change the
checked property

instead you would change the value in the bound
dataview.

Hope this clears up some questions.

Regards,

Stephen

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Robert Brown
Sent: Thursday, December 13, 2007 2:31 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] EpiViewNotification

I've found the same (making EpiViewNotification a rather useless event
trigger).

In some customization applications, you can replace the standard control
with a custom control and use the custom control to trigger what ever it
is you are trying to do.

I suspect controls tied to a view do so through a (poorly designed)
control-db layer that sustains a record lock condition that effectively
short circuits the EpiViewNotification.

My understanding is that both Progress and SQL Server support field
(versus entire record) locking during I/O actions. I hope Epicor
(perhaps in v9) does a rewrite of the layer so it results in less
contention for records during I/O actions. Going to field level locking
(for appropriate actions) would improve perceived user app performance
considerably.

Rob Brown

Michael McWilliams <mmcwilliams22@...
<mailto:mmcwilliams22%40yahoo.com> > wrote:
Has anyone else used this and had issues? If I have a control that
is tied to a DataView I cannot modify it using code after the
EpiViewNotification. But if a have a control not tied to the DataView
it will work. I though that this Event happened after the Table was
pulled in & the DataSet was ready to be modified.

---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
it now.

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]






---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search.

[Non-text portions of this message have been removed]
10
Hi Rob,

No not on the payroll

I did not say that the EpiViewNotification was the best
place to put this kind of code, as some things do not fire a change like
you mentioned and others fire several times,

often you will have an OnchangeOf event that you can
catch Via BPM or an after / before adapter call, or catch the column
changing event.

It all depends on the situation, like many of these
things.

If Michael could provide an example we could look at the
different approaches one could take...



Regards,

Stephen Edginton (Beng)

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Robert Brown
Sent: Thursday, December 13, 2007 8:44 PM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] EpiViewNotification



Thanks Stephen.

Fascinating (really). You sound like you're on the payroll at Epicor.

Optomistic record locking is one of those 'sounds good' ideas (to make
programming easier and the resulting UI responsiveness better) that has
turned out to be less than stellar in practice.

Hopefully we will see the last of it within the next few years.

None of your excellent explanations of VB.NET client/server interaction
gets at the problem:

EpiViewNotifications more often than not DO NOT WORK - even in cases
where I can see (via odbc) that the table data has indeed been updated.

If you have some definitive insight as to why, I'd truly love to hear
it.

If/until EpiViewNotifications prove to work reliably, I found it easier
not to waste time attempting to use them.

Other event triggers DO work 'as advertised' on a consistent basis so it
is a more efficient use of programming time simply to use them if
they'll get the job done. That was my advice to Micheal.

Thanks for the info.

Rob Brown

Stephen Edginton <stephene@...
<mailto:stephene%40dotnetit.co.uk> > wrote:
Rob,

Just to clarify some points.

The UI layer is all based on dataviews. This dataview is
the view of a particular dataTable. This dataTable is one of many in a
data set.

These objects are all in memory.

The process goes as follows - Client connects to
appservers - requests data, appservers querires database - returns a
dataset - a copy of the data.

The client then receives this dataset and the form
controls that are bound to a specific EpiDataView (encapsulated
dataview) are notified via the EpiViewNotification process.

At this point there is no record locking going on.
Anther user could open the same form - pull up the same information make
a save, then if you go to save again you get the

"this record has been modified by another user"

Hence it uses optimistic locking.

If you need to change the value of a bound control - you
do not change the control itself

i.e. a checkbox on the screen, you would not change the
checked property

instead you would change the value in the bound
dataview.

Hope this clears up some questions.

Regards,

Stephen

From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf
Of Robert Brown
Sent: Thursday, December 13, 2007 2:31 PM
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Subject: Re: [Vantage] EpiViewNotification

I've found the same (making EpiViewNotification a rather useless event
trigger).

In some customization applications, you can replace the standard control
with a custom control and use the custom control to trigger what ever it
is you are trying to do.

I suspect controls tied to a view do so through a (poorly designed)
control-db layer that sustains a record lock condition that effectively
short circuits the EpiViewNotification.

My understanding is that both Progress and SQL Server support field
(versus entire record) locking during I/O actions. I hope Epicor
(perhaps in v9) does a rewrite of the layer so it results in less
contention for records during I/O actions. Going to field level locking
(for appropriate actions) would improve perceived user app performance
considerably.

Rob Brown

Michael McWilliams <mmcwilliams22@...
<mailto:mmcwilliams22%40yahoo.com>
<mailto:mmcwilliams22%40yahoo.com> > wrote:
Has anyone else used this and had issues? If I have a control that
is tied to a DataView I cannot modify it using code after the
EpiViewNotification. But if a have a control not tied to the DataView
it will work. I though that this Event happened after the Table was
pulled in & the DataSet was ready to be modified.







[Non-text portions of this message have been removed]
11
I now have it working using the EpiViewNotification. I have no
explanation but for some reason I could not even get an OnClick to
work in this customization. No compile errors though. I have about
200 lines of code so maybe something else was causing a problem.

I started from scratch, pasted my code in from the other one. Then
added my controls & it works, go figure..
--- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...>
wrote:
>
> Hi Rob,
>
> No not on the payroll
>
> I did not say that the EpiViewNotification was the
best
> place to put this kind of code, as some things do not fire a
change like
> you mentioned and others fire several times,
>
> often you will have an OnchangeOf event that you
can
> catch Via BPM or an after / before adapter call, or catch the
column
> changing event.
>
> It all depends on the situation, like many of these
> things.
>
> If Michael could provide an example we could look
at the
> different approaches one could take...
>
>
>
> Regards,
>
> Stephen Edginton (Beng)
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
Behalf
> Of Robert Brown
> Sent: Thursday, December 13, 2007 8:44 PM
> To: vantage@yahoogroups.com
> Subject: RE: [Vantage] EpiViewNotification
>
>
>
> Thanks Stephen.
>
> Fascinating (really). You sound like you're on the payroll at
Epicor.
>
> Optomistic record locking is one of those 'sounds good' ideas (to
make
> programming easier and the resulting UI responsiveness better)
that has
> turned out to be less than stellar in practice.
>
> Hopefully we will see the last of it within the next few years.
>
> None of your excellent explanations of VB.NET client/server
interaction
> gets at the problem:
>
> EpiViewNotifications more often than not DO NOT WORK - even in
cases
> where I can see (via odbc) that the table data has indeed been
updated.
>
> If you have some definitive insight as to why, I'd truly love to
hear
> it.
>
> If/until EpiViewNotifications prove to work reliably, I found it
easier
> not to waste time attempting to use them.
>
> Other event triggers DO work 'as advertised' on a consistent basis
so it
> is a more efficient use of programming time simply to use them if
> they'll get the job done. That was my advice to Micheal.
>
> Thanks for the info.
>
> Rob Brown
>
> Stephen Edginton <stephene@...
> <mailto:stephene%40dotnetit.co.uk> > wrote:
> Rob,
>
> Just to clarify some points.
>
> The UI layer is all based on dataviews. This dataview is
> the view of a particular dataTable. This dataTable is one of many
in a
> data set.
>
> These objects are all in memory.
>
> The process goes as follows - Client connects to
> appservers - requests data, appservers querires database - returns
a
> dataset - a copy of the data.
>
> The client then receives this dataset and the form
> controls that are bound to a specific EpiDataView (encapsulated
> dataview) are notified via the EpiViewNotification process.
>
> At this point there is no record locking going on.
> Anther user could open the same form - pull up the same
information make
> a save, then if you go to save again you get the
>
> "this record has been modified by another user"
>
> Hence it uses optimistic locking.
>
> If you need to change the value of a bound control - you
> do not change the control itself
>
> i.e. a checkbox on the screen, you would not change the
> checked property
>
> instead you would change the value in the bound
> dataview.
>
> Hope this clears up some questions.
>
> Regards,
>
> Stephen
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> [mailto:vantage@yahoogroups.com <mailto:vantage%
40yahoogroups.com> ] On
> Behalf
> Of Robert Brown
> Sent: Thursday, December 13, 2007 2:31 PM
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: Re: [Vantage] EpiViewNotification
>
> I've found the same (making EpiViewNotification a rather useless
event
> trigger).
>
> In some customization applications, you can replace the standard
control
> with a custom control and use the custom control to trigger what
ever it
> is you are trying to do.
>
> I suspect controls tied to a view do so through a (poorly designed)
> control-db layer that sustains a record lock condition that
effectively
> short circuits the EpiViewNotification.
>
> My understanding is that both Progress and SQL Server support field
> (versus entire record) locking during I/O actions. I hope Epicor
> (perhaps in v9) does a rewrite of the layer so it results in less
> contention for records during I/O actions. Going to field level
locking
> (for appropriate actions) would improve perceived user app
performance
> considerably.
>
> Rob Brown
>
> Michael McWilliams <mmcwilliams22@...
> <mailto:mmcwilliams22%40yahoo.com>
> <mailto:mmcwilliams22%40yahoo.com> > wrote:
> Has anyone else used this and had issues? If I have a control that
> is tied to a DataView I cannot modify it using code after the
> EpiViewNotification. But if a have a control not tied to the
DataView
> it will work. I though that this Event happened after the Table
was
> pulled in & the DataSet was ready to be modified.
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>