Having multiple validation errors in single error message in Peoplesoft - peoplesoft

Is it possible to get multiple error messages for missing required fields in a single error message to the user? For example, if I left all 5 of my required fields blank, the error message that is displayed when clicking Submit will show all 5 messages in the same window.

This is a fantastic idea and should be added to the PeopleSoft Idea Spaces in MyOracle Support. Unfortunately, this is not delivered. There are multiple ways a person might trigger an exception, including:
Choosing an invalid value
Leaving required fields blank
Failing FieldEdit or SaveEdit PeopleCode
Unfortunately, PeopleSoft fails on the first, not all. Regarding the last item: FieldEdit/SaveEdit, as soon as you trigger the PeopleCode Error function, PeopleCode halts, so it is impossible for us to use the Error function to queue multiple exceptions.
With all that said, nothing is impossible. One way to accomplish this would be to use our own JavaScript/CSS to mark all fields that fail validation. This would require us to write additional PeopleCode, etc., to work around Oracle's delivered validation.

One approach to do that is to perform the validations "manually", stack then and present to the user.
In order to do that, you need to have a custom "Save" or "Validate Button", and your peoplecode would stack the errors.
You can use the vanilla required fields validation + any conditional validation you need.
A good way to present this is just have a field(long) or an html area and nicely present the errors:
Emplid is required
Setid is required
Enter an end date less than start date
But otherwise, this is not part of Peopletools, although some modules do offer this (eSupplier Portal for instance has a similar feature).

Related

Hibernate Validator Depends on

Is there a way to achieve depends on behavior with hibernate validation. For instance if i have two custom validations
#InvalidAmount // Validates the amount is invalid with some custom logic
#AmountNotAccepted // Validates the currency is not accepted along with some custom logic
The idea is not to merge both of them together and throw second error only if the first one succeeds. Is there a way to do it? Something like run the second validate only first first is not an error.
For example:
#AmountNotAccepted(dependsOn = {InvalidAmount})
You may be after group sequences?

Google App Maker Widget Validate on Datasource select

I have three different fields/textbox widgets, that rely on querying the same data source to be checked to avoid duplication. For reasons, I do not want to turn on the unique/required for those three fields.
I put some code to check for validation. My problem is that when I call the form's validate function, it takes some time till the validation comes back with an error message. However the form's validate returns immediately and allows people to click Submit.
How can I avoid this problem?
Block till validation kicks (setTimeout function?)
Set a separate invisible field such as working and set the validationError on the field and clear after validations clear? This will probably be a numeric field so that I can wait for all streams in parallel to finish.
Final question. is Validate a blocking function as it goes through the fields? I am guessing Yes.

Entity Framework table updates not working due to trigger calling CLR

I have a table with a trigger that points to an assembly:
CREATE TRIGGER [dbo].[triggername] ON [dbo].[tablename]
WITH EXECUTE AS CALLER
AFTER DELETE, UPDATE
NOT FOR REPLICATION
AS EXTERNAL NAME [Namofassembly].[blahblah].[blahblah]
We also using code first EF in .net 4.
When I use delete everything works fine but the trigger does not get called.
dataRepo.UsersPermanentAuditAssignments.Remove(isInsertFound)
When I use update I get a permissions error. This is either when I try it through the object model or a dataRepo.Database.ExecuteSqlCommand(updateSql)
System.Data.SqlClient.SqlException: The context transaction which was active before entering user defined routine, trigger or aggregate "name" has been ended inside of it, which is not allowed. Change application logic to enforce strict transaction nesting.
Everything works fine when I run the queries via the sql management studio.
I also am not able to change this configuration so while I don't care for this design I am not able to change it.
My questions are:
1> Why would the delete not get logged but work?
2> Do I need to add something extra to my repo configuration object that will allow this to work? Do I need to add some transaction like unitofwork before I start this since it has a trigger maybe?
I have figured out the causes of this issue.
It relates to having a composite primary key (station,user) and trying to update one of the values.
I could not update any column of the primary key, ie change the user assigned to a station.
The trigger failure masked the issue of not being able to update a value inside the key.
My experiments show the following for the compositekey/pk update:
Method History Trigger Result
EF.SaveChanges Enabled Fail at trigger
EF.SaveChanges Disabled Fail at trigger
EF.ExecuteSQLCommand(sql) Enabled Fail at trigger
EF.ExecuteSQLCommand(sql) Disabled Works
Unfortunately, I don't have the ability to change to a surrogate with a unique index which would work. Also, the trigger CLR prevents me from using DataBase.ExecuteSQLCommand(sql) also which I believe is actually a problem with the CLR of which I have not ability to modify.
So my advise (that I can't take) is if you get this use a surrogate key and a unique index instead of combining the 2.
If anyone knows any way to allow EF to allow you to change a value inside a composite/primary key please comment.

ASP.NET - displaying business layer errors in the presentation layer

Currently in the ASP.NET application I'm developing, basic validations (ie required fields) are being done in the Presentation Layer, using Validators and a ValidationSummary. This is working great for me specifically since the ValidationSummary will display multiple error messages (assuming multiple Validators are set to invalid).
I also have some validations being done in the business layer - due to their complexity (and data service layer reliance) I'd rather not keep them in the presentation layer. However, I'm not sure the best way to send these back to the presentation layer for display to the user. My initial consideration is to send back a List<string> with failed validation messages and then dynamically create a CustomValidator control (since apparently you can only bind one error message to one Validator control) for each error to show in the ValidationSummary when there are any.
I'm assuming I'm not the first one to come across this issue, so I'm wondering if anyone has any suggestions on this.
Thanks!
There are essentially two ways to do this: either by passing back an error code/object from your business layer, or throw out an exception. You can also combine both.
For an example, you can take a look SqlException class. When you send a SQL to SQL Server, it runs a query parser to parse your SQL first. If it sees syntax error, then it will throw out a SqlException and terminate the query. There may be multiple syntax errors in your query. So SqlExeption class has an Errors property that contains a list of errors. You can then enumerate through that list in your presentation layer to format your error message, probably with a CustomValidator.
You can also simply just return the error list without throwing an exception. For example, you can have your function to return a List in case at least one error occurred and return null in case the call was successful. Or you can pass List as an argument into your function. They are all fine, it all depends on which way you feel is more convenient. The advantage of throwing out an exception is it unwinds multiple call frames immediately, so you don’t have to check return value on every level. For example, if function A calls function B , B calls function C, C sees something wrong, then if let C to return an error object (or error code), then B has to have code to check whether C returned an error and pass that error code/value back, A have to check it as well ---- you need to check it on every level. On the other hand, if you just let C to throw an exception, then the code goes straight to the exception handler. You don’t have check return values on every level.

error handling in asp.net

How can i pass the different types of errors from Data access layer to presentation layer?
suppose if we take the northwind database
scenario
I want to delete the customer, so i selected one customer in ui and clicked the "delete" button.It internally calls the "delete" in data access layer.
The prerequisite for deleting the customer is that the customer doesn't have any orders.So in data access layer we wil check whether that customer has any orders.If the customer has orders how can we pass the message from dal to presentation layer that the customer has orders and we don't delete.
Am i doing right?is there any other ways to deal with this type?
Thanks in advance
The other answers tell you how you should be implementing this particular scenario, however to answer your original question, the answer is to define your own exceptions.
You can have a core DataLayerException as the base for all of you data exceptions (inheriting from ApplicationException or similar) then have sub exceptions based on the scenario, e.g.:
ConnectionClosedException
TImeoutException
etc.
For me personally, it would be better to call a separate "ValidateDeletion" method prior to attempting a delete. This would first check to see if that customer has orders before removing them from the database.
Particulary, if you want to raise different kinds of exception from database... I use to raise an error from SP like this.
if (#invalidCount <> 1)
Begin
Raiserror('[Duplicate] Record Already Posted In System ', 20, 1)
End
Catch the error in the DAL, and analyse the exception type through the exception message (here the keyword for me is the "[Duplicate]") and throw the different kind of exception appropriately.
Of course this will be very cumboresum if you have more than 2/3 types of exceptions.
For me the best way is to raise an event TryToDeleteCustomerWithOrders.
The validation part is also fine, but it's about data, so the data layer should do the whole work. If you put the validation outside, there is chance that you call the deletion function without validation ....

Resources