I do not think we can change form definition dynamically ..if it is then its useful
You might be able to "generate" your set of forms by editing the form-name + table-name in a def-file, and import it. You will still get a bunch of forms, but it is not that hard to do.
You can then add the bunch of forms to the workflow, to have all workflow shared across the forms.
Best Regards - Misi, RRR AB, http://rrr.se
Infact you can make your Table dynamic, which inturn can make make the View Form Dynamic.
You can create a view which fetches data from multiple forms and depending upon certain conditions you can decide which form data to show at what time in same table.
1 of 1 people found this helpful
Even I think its not possible following is the reason behind it.
- Every field exist in db view mapped with the remedy field and the mapping is static. Please verify it in form AR System Metadata:view_mapping.
So everytime when view get changed the mapping in arsystem metadata:view_mapping (or view_mapping table) must be updated.
Thanks for the response.
This is what we are currently following. Otherwise it will be more time consuming and redundant to arrange the all the fields in a proper order.
actually, i am looking for a way to reduce the number of view forms created.
not sure but in case if you require the table name to be renamed then there could be a problem when multiple users try to retreive data.
1 of 1 people found this helpful
I was looking for something similar for some time. Your suggestion actually reawakened the investigation. I didn't realize there were metadata tables. I wanted to modify the table name on the view but it's read only in developer studio. I can't change it. I don't want to recreate a view form just because the associated table name is different.
First, I tried exporting the definition file for the form. Then I opened up the def file in a text editor (so as careful not to modify the integrity of the file itself). Under where it reads schema-type : 3, there are two fields indented called ext-table and key-field. I modified the ext-table value and thought this would change it. I tried importing the definition file and the import failed because of structural integrity error of the data. I'm confident it's because I changed the ext-table value.
In my SQL management application, I searched for the T table mapped to the schemaID of the view form, via the arschema table. Let's use T123 in this example. I edited the T123 table query -- it's just a SQL view -- to map to a different SQL table of my choosing, i.e. ExtDB.dbo.MyNewTable. This does work effectively and will query the new table, but it's not consistent and may lead to strange behavior in Developer Studio, since the read only field for the table will still read the original SQL table name, i.e. ExtDB.dbo.MyOldTable.
I needed to keep looking. I eventually found a table called schema_view which lists the table name and key field, labeled tableName and keyField, respectively. It is here where you can rename the table. Make sure you use the FQTN, as in database.schema.table or similar. In my example, MyOldTable and MyNewTable are exactly the same under the covers, but I didn't like the table name. If this is all that is required, then editing schema_view and changing the query for T123 to map to MyNewTable is all it takes. Unless you need the old table for some reason, you could have renamed it directly, especially if the design of the tables are the same and the data sets are equal, instead of creating a new table with a new name and the same structure underneath.
If you need to point to new table with a different structure, read this part. There's a table called view_mapping which has two notable columns called fieldId (i.e. T123 columns) and extField (i.e. MyOldTable columns). If your new table has a completely different structure underneath, you'll need to reflect those changes in the view_mapping table. It's associated SQL view is AR_System_Metadata_view_mappi. arschema also has a SQL view, but I couldn't find one for schema_view. You also could have found the T123 by traversing through SQL views and finding the name that is similar to the name of the view form, i.e. Remedy_View_Sample_Form. The way it works is Remedy creates the T123 table -- which is really just a SQL view that's mapped to your external SQL table. And it also creates a SQL view -- whose name is similar to the view form name -- that is mapped to this same T123 table. Of course, you'll need to ensure the queries for both T123 and Remedy_View_Sample_Form are properly reflected in these changes.
Finally, and this is VERY important, to finalize the changes such that they reflect in Developer Studio, you must restart BMC Remedy AR. In my case, it's a windows service. If, for some reason, the table name is not updated on the view form in Developer Studio, restart SQL. Again, in my case, it's a windows service. Through testing, I have found that the view form works fine and queries the new table, even if the table name has not changed in developer studio. Why? Because the view form is working directly from T table, i.e. T123. I believe Remedy caches some SQL data for Developer Studio, hence a restart of the AR service. If, for some reason, restarting the AR and SQL services don't do the trick for Developer Studio, you can export and then re-import the form, but you must only do this AFTER you have at least restarted the AR service.
Start of rant:
It's a long post but I hope it helps others out there who needed to change the table name. I can't understand why it would be read-only in Developer Studio. Stupid. Maybe the developers didn't have sufficient time to code it, I don't know. If it was up to me, I'd code everything myself, but I'm forced to use this system.
There is a good possibility that you were unable to rename the form through developer studio because it is an OOB form and it's a base form. In order to be able to rename it, you would need to put developer studio into Base Development mode which will allow you to make any changes you want to any Base forms without creating an overlay. These forms are un-editable in Best Practice Mode in order to force the use of Overlays which will prevent most customizations you create from being overwritten on the form whenever a patch or upgrade is applied. Even if this isn't an OOB form and is in fact a custom form then there is a good chance that the person that created the form manually set it as a Base form. It is not usually a good idea to rename tables directly through SQL since most tables will have a T, B, and H table that go with them. For more information on overlays please see these posts:
Thank you very much. Unfortunately, I am on version 7.5 patch 006. I don't think there is a base development mode in this version and I cannot upgrade at this time. If base mode exists in 7.5, I'd love to explore it. But based on the articles you included -- which was very thoughtful of you -- that doesn't appear to be the case. To reiterate, the form type is a view.
I understand the warnings about directly modifying through SQL. I know some people are not comfortable with it and could potentially break something. But I'm confident in my approach; I tested it thoroughly and have no concerns. For those who are very comfortable working with SQL and studying the schemas and are using an older Remedy version that cannot be upgraded, my approach is a worthy alternative. Again, if there is some sort of admin mode to directly edit objects with version 7.5 -- whether it's called Base Development Mode or something else entirely -- I'm all ears.
Thanks for the screen cap. I am using version 7.5 of Remedy and 7.5 of Developer Studio. I do not see a Switch Mode option in the File menu or anywhere else. I would love to upgrade to 7.6 Developer Studio, but I am afraid that decision is not up to me. It's good to know that it's backward compatible with ARS 7.5, though.
Thank you for enlightening me and your help.
No problem. Thanks for the quick follow ups.
Dev Studio is aware of which AR versions are compatible with overlays (Base and Best Practice modes). Overlays were introduced in 7.6.04. Dev Studio later than 7.6.04 will not show you the switch mode options with a pre 7.6.04 server.
Changing the view definition (what table/db the View Form pulls from) has always been a challenge. I am pretty sure the old Admin Tool before Dev Studio did not allow changing these either. The easiest way has been to export the View form (or Vendor Form for that matter) to a def file, change the references in a text editor and import the def file over the form.