Jump to content

NiceDuck

Caspio Guru
  • Posts

    241
  • Joined

  • Last visited

  • Days Won

    11

NiceDuck last won the day on March 26

NiceDuck had the most liked content!

4 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Okay, I just checked. You can also have a virtual field on search forms, but the virtual fields on the search form cannot use a calculated value as a form element.
  2. As mentioned above by @LittleMsGinger, the idea is to have a calculated value to convert the selected values from their actual value to their display value. However, take note that this will only work if you are coming from a form type of datapage (Submission, Single Record, Report Details) since these are the only page that has a virtual fields.
  3. If you are on a form type of datapage, you can try using this workflow where they converted it first on a comma seperated values on a virtual field then use that comma seperated values for your calculation. I hope this helps.
  4. I'm afraid that we cannot access list string fields on calculated fields, the same with the calculated values and formula fields.
  5. The one I have provided to you is for datapage level (specifically, form types such as submission form, SRUpdate and report details page since they are the only one that can have a virtual parameter). It can be done directly on the formula field as well but you will have to significantly change the formula.
  6. Okay, lets I'm gong suggest some step here part by part. first thing you need to have is the SQL formula for isolating the 6 digit number you have. Once you have it isolated, you can use something like this. On my case, the isolated 6 digit number is on the virtual 1. CONVERT(DATETIME, SUBSTRING('[@cbParamVirtual1]', 1, 2) + '/' + SUBSTRING('[@cbParamVirtual1]', 3, 2) + '/20' + SUBSTRING('[@cbParamVirtual1]', 5, 2), 101)
  7. Hello Im kinda bit shocked when I saw your formula. TLDR, Anyway, what I can suggest for you on that case is, try not to use all of the formula in one go. For example, Use only the first when and then, then go preview it and see if the issue persisted. Basically, try the formula part by part to trace which part of it is causing the issue.
  8. Just a short note to differentiate them: Triggers: Runs based on table activity (insert/update/delete) Is attached to a specific table as its parent Task: Runs on demand or on predefined Schedule.
  9. I really think that the formula field runs first. If you have a formula field on your table and you insert a record on it, the #inserted.Formula_field will already have value which you can use.
  10. you said that this field is unused thus you probably checked this already but you may want to check your table relationship as well. If that field is being used there, it would show you the same error.
  11. I'm not sure what you mean by creating a new field. You can use the formula field on the table design to generate values base on what you currently have on your table but we cannot use that to create a new field/column.
  12. This should be my setup without the for each loop. I know that the table variable will surely not have any records on it on initial setup but I still keep the delete action block just for the sake of my paranoia.
  13. I'm not sure if I'm correct, but as I read your trigger, you will have a conflict on the result there if you happen to have multiple inserts and updates with different Parent ID. It will end up giving the same AVG values to different parent records.
  14. @TellMeWhy The For Each? Good question. Lets just say that it is a way of making sure that the trigger will still work on the cases where there are more than 1 records inserted or updated (Bulk Insert/Update). Most of the trigger setup is design to accommodate only 1 record at a time and tend to fail or return an incorrect result during bulk inserts and updates. That is why I am using a 'for each' loop so the trigger blocks will process the contents/records of the #inserted 1 by one. Of course, there are better ways to setup your trigger to optimize it and make it adaptive to bulk inserts. Still, let just say that the use of 'For Each' loop is a 'default' or 'basic' way and works most of the times. It kind of slows your trigger though, specially when lots of records are being involved.
  15. NVM, I figured it out. Turns out that I will need to compile all the records first into a table variable then get the average values from there.
×
×
  • Create New...