Watch, Follow, &
Connect with Us

QualityCentral

Public Report
Report From: Delphi-BCB/Midas/TDataSetProvider    [ Add a report in this area ]  
Report #:  5592   Status: Closed
New event OnValidate that is fired before applying updates
Project:  Delphi Build #:  7.0.4.453
Version:    7.0 Submitted By:   Serge Dosyukov
Report Type:  Suggestion / Enhancement Request Date Reported:  8/11/2003 10:02:36 AM
Severity:    Infrequently encountered problem Last Updated: 3/20/2012 2:24:39 AM
Platform:    All platforms Internal Tracking #:   216031
Resolution: Fixed (Resolution Comments) Resolved in Build: : 9.0.1935.22056
Duplicate of:  None
Voting and Rating
Overall Rating: (1 Total Rating)
2.00 out of 5
Total Votes: None
Description
Event wich will happened before transaction is opened in Apply Updates cycle. Will allow perform Validation logic on a server.

This cannot be done in BeforeApplyUpdates, because Delta is not avalable without reintroduction of component
Steps to Reproduce:
None
Workarounds
None
Attachment
None
Comments

Dave Rowntree at 8/12/2003 4:31:13 AM -
Another option could be to request the DSP.BeforeApplyUpdates event parameters be extended to include a DeltaDS, and maybe the MaxErrors value might also be useful.

The DSP.BeforeApplyUpdates event fulfils all the requirements with the exception of the availability of the DeltaDS. Extending this event would save the un-necessary addition of yet another event when one already exists that nearly fits the bill.

The downside of this would be that it changes the event parameters signature, which would affect existing DSP.BeforeApplyUpdates events. It would mean re-creating or amending them in existing app code. IIRC Borland made event signature changes in MIDAS 3 which had the same effect.

Serge Dosyukov at 8/13/2003 9:48:21 AM -
Yes, this is possible, but this will change current event structure
which potentially could broke someone application
this is why I did request new event

Dave Rowntree at 8/13/2003 1:24:07 PM -
I see a change of the DSP.BeforeUpdateRecords event signature preferable to introducing yet another event, to be called at the same time as the BeforeApplyUpdates event, to do the same job as BeforeApplyUpdates, the only difference being the inclusion a DeltaDS as a parameter.

Serge Dosyukov at 8/14/2003 9:21:06 AM -
If I remember correctly, to expose Delta at specified moment, IAppServer
should be extended to pass such information. Because at this moment Delta is
not ready yet. Untill we trying extract it from Data property data.
So if we will touch specified event then this will require to have changes
in interface as well as event declaration.
If it will be introduced as a new event it will not changed existing
paradigm.

Dave Rowntree at 8/14/2003 2:35:29 PM -
>>
Serge Dosyukov said - "If I remember correctly, to expose Delta at specified moment, IAppServer
should be extended to pass such information.
<<

Not necessary. IAppServer is only used in calls between the client and the appserver, and already passes the Delta from the CDS to the DSP.

>>
Because at this moment Delta is
not ready yet. Untill we trying extract it from Data property data.
<<

Correct. However, the OleVariant Delta is not converted into a TPacketDataSet DeltaDS until after the DB transaction has been started by MIDAS.

>>
So if we will touch specified event then this will require to have changes
in interface as well as event declaration.
<<

If you mean the IAppServer interface then no.

>>
If it will be introduced as a new event it will not changed existing
paradigm.
<<

Yes it will. As I said, the OleVariant Delta is not converted into a TPacketDataSet DeltaDS until after MIDAS has started the DB transaction. Either way, changes will be necessary to the current internal architecture.

Serge Dosyukov at 8/25/2003 1:45:44 PM -
DR> Not necessary. IAppServer is only used in calls between the client and the appserver,
DR> and already passes the Delta from the CDS to the DSP.
DR> Correct. However, the OleVariant Delta is not converted into a TPacketDataSet DeltaDS
DR> until after the DB transaction has been started by MIDAS.

I do not see a problem to convert OleVariant into TPacketDataSet.DeltaDS one step earlier if OleVariant is correct and available, so DeltaDS (which could be exposed as a property) will be populated

DR> Either way, changes will be necessary to the current internal architecture.

So only reason why it couldn't be implemented is because it will change internal communication even if it will provide more information for user?

Dave Rowntree at 9/4/2003 10:04:02 AM -
Serge Dosyukov said - "I do not see a problem to convert OleVariant into TPacketDataSet.DeltaDS one step earlier if OleVariant is correct and available, so DeltaDS (which could be exposed as a property) will be populated

That is something Borland will decide.

DR> Either way, changes will be necessary to the current internal architecture.

SD>So only reason why it couldn't be implemented is because it will change internal communication even if it will provide more information for user?

I did not say that. Personally, I see this requirement as being of limited benefit, and the required investment to implement it being rather heavy. A far simpler solution may well be to add a Delta:OleVariant parameter to the DSP.BeforeUpdateRecords event. That would require far less investment. Whether the community would want this is another matter. If this report receives support from the community I am sure it will be opened.

I have changed the report Severity from 2 to 3.

Robert Cerny at 8/12/2003 8:56:53 AM -
I dare to disagree. :)
If you have to check data integrity per se (=no database lookups needed), you should do it on client side (before post). If validation needs database lookup, it's a lot more cost effective to do that in trigger.

Luigi Sandon at 8/12/2003 9:26:49 AM -
> If validation needs database lookup, it's a lot more cost effective to do that in trigger.

Not in the case you would like to put the validation logic in the app server to be as much as possible database neutral. Or if the validation is failry complex and can be easily coded in Delphi but not in a database language, never used SQL Server, its awful Transact-SQL language, and its horrible trigger support? Or maybe one can use a back end without triggers, maybe just some XML or .dbf files, or the like.

If app server are just a pipe from/to the database, well, get back to C/S! :-)

Server Response from: ETNACODE01

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.