I want to be able to restrict the user from entering special characters like !@#$% in a text field in a form. I could not find any such utility in the Form Builder or Data Modeler. If my understanding is correct, I should be using a workflow for this. But I am not sure how to do it. Any suggestions?
Do you want the field to disallow spaces and numeric characters, as well as special characters like !@#$%? If yes, then Validation > “Alpha Only no Spaces” through Data Modeler may help you…
If you opt to go the workflow route, you could have a switch that uses a few Contains() statements to check for the individual characters you don’t want, but I don’t know how well that function will work with special characters. You may want to look at using the isStringPatternMatch() function, as described in this thread.
[Admin: To see other related posts, use the Character tag.]
I am uploading a tab-delimited file and writing the data into a staging table using TRIRIGA integration object. While uploading the file, I need to restrict the number of lines that can be uploaded into the staging table. I am using DataConnect and a custom task to read the file from the binary field. But I am not able to read the file. How can we read the file from the integration object?
[Admin: To see other related posts, use the Integration Object tag, Staging tag, or DataConnect tag.]
We have an issue from a user where he mentions that “Report filters for dates are not displaying properly”. This issue is happening when the user is using the triCreatedSY field in user filters. I added a date-time field to an existing report and chose the filter of “After”. When I run the report, the filter says “Contains” that also does not work. I entered the date of one of the items in the report and it did not return that item…
The system is providing the filter operator similar to the date fields, but it is not working no matter what date we give or what operator we use. We tried the same for other date fields which ends with “DT” but those work fine. I looked in the field properties of the triCreatedSY field and found the property “Sub Attribute Type = Created DateTime (Number)”. In the TRIRIGA user guide (PDF), I found the following information…
My understanding is if the user wants to use the triCreatedSY field, then we have to add a field “Created DateTime Number” on the BO. Based on the PDF, when I added a field on the BO, no information is getting populated in that field. It looks like there should be a way to map it. Is my understanding correct? Will it be a good solution to apply the changes as mentioned in the user guide? Or can we suggest an alternative to the user?
The triCreatedSY field is actually a timestamp field, so it acts like a string. You’ve started in the right direction by creating a new Created DateTime field, but it needs to be a Field Type = “System Read Only” and the Sub Attribute Type = “Created DateTime (Number)”. Note that previously created records will not have this field populated.
[Admin: To see other related posts, use the Filter tag or Date tag.]
I added a new date field, cstReminderDateDA, to a custom business object. For existing records, there is a requirement that cstReminderDate be set to the value of an existing date field (cstDueDateDA) minus 30 days, i.e. cstReminderDateDA = (cstDueDateDA – 30). This would be pretty straightforward, except that both cstReminderDateDA and cstDueDateDA are stored as numeric fields in our Microsoft SQL Server database. How do I populate cstReminderDateDA?
IBM TRIRIGA stores the date as epoch time. See the following wiki link explaining this. If you do some searching, you will find some functions available for SQL Server for data calculations.
[Admin: To see other related posts, use the Epoch Time tag.]
What is the best way to handle calculated fields that need to reference the Current Date or System Date? For example, I have a number field in the Building BO called Building Age. To calculate the Building Age, I had to create another field called “cstCurrentDateDA” to store the current date the Building record was created.
From there, I take the Current Date minus the In Service Date of the building. However, let’s say I wanted the Building Age field to get updated daily. In my current design, I would have to probably create an asynchronous workflow to update the “cstCurrentDateDA” field and then trigger a Save action to get the extended formula against the Building Age field to fire.
Is there a better approach to dealing with field variables that rely on the Current Date or System Date? Instead of creating a custom field to store the Current Date to act as a constant factor?
[Admin: To see other related posts, use the Date tag.]
We have already upgraded our platform to 22.214.171.124. We are currently in the process of upgrading our application from 10.3.2 to 10.5.2.
For the application upgrade, we have set up a staging environment with an initial install of 10.5.2 and we have configured all BOs, forms, and other objects to meet our current customization. My question is: What if we import the IBM upgrade OM packages (sequential from 10.4 to 10.5.2) to our current environment (which has all customization)? It would definitely overwrite all the customization and configuration, but does it affect the record data as well (e.g. lease records)?
When it overwrites the customization at the BO and form level, would it corrupt the record data since some of the custom fields on the records won’t exist at the BO level any more? And what happens after we import all our customization back in the current environment from the staging environment?
The short answer is: You wouldn’t apply the IBM upgrade OM packages. Instead, you’d build OMs in your now customized 10.5.2 environment and then apply them to your current environment.
[Admin: To see other related posts, use the Object Migration tag or Upgrade tag.]
Is there a way to query which label class is being used on which fields? I want to tweak the existing ones slightly, but I’m not sure what is going to be updated when I make the change.
[Admin: To see other related posts, use the Labels tag or Query tag.]