Possible Table field Enhancement
Well, I don't think you can already do this, but I could see it coming in use occasionally. I would like to have the ability to set the contents of a table using Direct SQL and external(). This way I could dynamically build a query string, then use external to present it to the table field. I would like to see Direct SQL as an option in the 'Form:' field on the Table Property tab in the admin tool. The 'Field on Form:' and the 'Field as Column' areas would be blank, as they would just pull the list of fields from your SQL statement. You would enter your SQL (hardcoded) or the External() function in the current 'Qualification bar' on the Table Property tab. They do this functionality with Set Fields. You have the option to select Direct SQL as an option to choose SQL in the 'Read Value for Field From:' field instead of choosing a form or the current transaction. I would like to see this mimicked in a Table field. I've only needed this twice, and both times have had to identify a work-around. I don't want to have to create an SQL view in the database every time I need to work around this. What is your input? Have you come across a situation where this would be handy (such as when you need to join two tables)? Another solution that would have worked for me in the past is if I could have chosen multiple remedy forms to pull in data to my table, using a join statement in the 'Qualification bar', and going through the GUI to choose which fields show up from each form, similar to when you create a join form. The reason why I don't just create a join form to start out with is that in remedy, you cannot create a join form of two view forms, and you can only create joins of other remedy views. I don't want to have to go out to the database, create my own non-remedy join of the tables from which the other views pull from, and then point a view form on top of that join so that I can access it in a table. Also, this would allow me to be much more flexible in which data I present in a table. Instead of having multiple tables layered on top of each other, I can just dynamically send them their own SQL qualification and use only one table, just changing the contents it displays based on the user, or based on some other options the user chooses. This could really eliminate the need for using multiple table fields in a lot of situations which I've seen. Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Possible Table field Enhancement
First off I agree with you...it would be nice to be able to do this...but one of the complications associated with this is the fact that columns in tables use field ID's...those field ID's are used for things like colsum and such and wouldn't be available in these 'dynamic' tables. The only thing you would be able to do with these dynamic tables would be to display information...you wouldn't be able to interact with any of the data in any way because none of the columns exist and you wouldn't be able to write workflow against the nonexistant columns. I agree and have come across several instances where this type of thing would have been useful...but with my 'problem' defined...it makes the capability less interesting/useful _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Opela, Gary L Contr OC-ALC/ITMA Sent: Thursday, August 16, 2007 6:46 AM To: arslist@ARSLIST.ORG Subject: Possible Table field Enhancement ** Well, I don't think you can already do this, but I could see it coming in use occasionally. I would like to have the ability to set the contents of a table using Direct SQL and external(). This way I could dynamically build a query string, then use external to present it to the table field. I would like to see Direct SQL as an option in the 'Form:' field on the Table Property tab in the admin tool. The 'Field on Form:' and the 'Field as Column' areas would be blank, as they would just pull the list of fields from your SQL statement. You would enter your SQL (hardcoded) or the External() function in the current 'Qualification bar' on the Table Property tab. They do this functionality with Set Fields. You have the option to select Direct SQL as an option to choose SQL in the 'Read Value for Field From:' field instead of choosing a form or the current transaction. I would like to see this mimicked in a Table field. I've only needed this twice, and both times have had to identify a work-around. I don't want to have to create an SQL view in the database every time I need to work around this. What is your input? Have you come across a situation where this would be handy (such as when you need to join two tables)? Another solution that would have worked for me in the past is if I could have chosen multiple remedy forms to pull in data to my table, using a join statement in the 'Qualification bar', and going through the GUI to choose which fields show up from each form, similar to when you create a join form. The reason why I don't just create a join form to start out with is that in remedy, you cannot create a join form of two view forms, and you can only create joins of other remedy views. I don't want to have to go out to the database, create my own non-remedy join of the tables from which the other views pull from, and then point a view form on top of that join so that I can access it in a table. Also, this would allow me to be much more flexible in which data I present in a table. Instead of having multiple tables layered on top of each other, I can just dynamically send them their own SQL qualification and use only one table, just changing the contents it displays based on the user, or based on some other options the user chooses. This could really eliminate the need for using multiple table fields in a lot of situations which I've seen. Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Possible Table field Enhancement
Remedy would just have to deal with the columns. Give them generic column ids. Whenever you select a row, click on a button, then you should be able to reference the row by the value in the row you clicked on. It should act just as it does now. You could display to the manager a list of tickets pending his/her approval. The manager select the ticket she/he wants to approve, approves it, then your workflow fires based on the request id column. Remedy should be able to take care of the column IDs by assigning generic column IDs if it needs to. Thankfully, that part isn't up to us :) It's just our job to define a need, and theirs to define a solution. Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of L. J. Head Sent: Thursday, August 16, 2007 10:48 AM To: arslist@ARSLIST.ORG Subject: Re: Possible Table field Enhancement ** First off I agree with you...it would be nice to be able to do this...but one of the complications associated with this is the fact that columns in tables use field ID's...those field ID's are used for things like colsum and such and wouldn't be available in these 'dynamic' tables. The only thing you would be able to do with these dynamic tables would be to display information...you wouldn't be able to interact with any of the data in any way because none of the columns exist and you wouldn't be able to write workflow against the nonexistant columns. I agree and have come across several instances where this type of thing would have been useful...but with my 'problem' defined...it makes the capability less interesting/useful From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Opela, Gary L Contr OC-ALC/ITMA Sent: Thursday, August 16, 2007 6:46 AM To: arslist@ARSLIST.ORG Subject: Possible Table field Enhancement ** Well, I don't think you can already do this, but I could see it coming in use occasionally. I would like to have the ability to set the contents of a table using Direct SQL and external(). This way I could dynamically build a query string, then use external to present it to the table field. I would like to see Direct SQL as an option in the 'Form:' field on the Table Property tab in the admin tool. The 'Field on Form:' and the 'Field as Column' areas would be blank, as they would just pull the list of fields from your SQL statement. You would enter your SQL (hardcoded) or the External() function in the current 'Qualification bar' on the Table Property tab. They do this functionality with Set Fields. You have the option to select Direct SQL as an option to choose SQL in the 'Read Value for Field From:' field instead of choosing a form or the current transaction. I would like to see this mimicked in a Table field. I've only needed this twice, and both times have had to identify a work-around. I don't want to have to create an SQL view in the database every time I need to work around this. What is your input? Have you come across a situation where this would be handy (such as when you need to join two tables)? Another solution that would have worked for me in the past is if I could have chosen multiple remedy forms to pull in data to my table, using a join statement in the 'Qualification bar', and going through the GUI to choose which fields show up from each form, similar to when you create a join form. The reason why I don't just create a join form to start out with is that in remedy, you cannot create a join form of two view forms, and you can only create joins of other remedy views. I don't want to have to go out to the database, create my own non-remedy join of the tables from which the other views pull from, and then point a view form on top of that join so that I can access it in a table. Also, this would allow me to be much more flexible in which data I present in a table. Instead of having multiple tables layered on top of each other, I can just dynamically send them their own SQL qualification and use only one table, just changing the contents it displays based on the user, or based on some other options the user chooses. This could really eliminate the need for using multiple table fields in a lot of situations which I've seen. Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Possible Table field Enhancement
This is something that I had written here as well as I remember writing an RFE for long long ago. A workaround to what you would like to do is creating a view form and a table field on that view form. The view form could be a table view with exactly the SQL that you want. However this would not work if you were to require an SQL to be dynamically generated based on workflow. In that case it does look like we do need the table field idea to be extended to the output generated by select. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA Sent: Thursday, August 16, 2007 8:46 AM To: arslist@ARSLIST.ORG Subject: Possible Table field Enhancement ** Well, I don’t think you can already do this, but I could see it coming in use occasionally. I would like to have the ability to set the contents of a table using Direct SQL and external(). This way I could dynamically build a query string, then use external to present it to the table field. I would like to see Direct SQL as an option in the ‘Form:’ field on the Table Property tab in the admin tool. The ‘Field on Form:’ and the ‘Field as Column’ areas would be blank, as they would just pull the list of fields from your SQL statement. You would enter your SQL (hardcoded) or the External() function in the current ‘Qualification bar’ on the Table Property tab. They do this functionality with Set Fields. You have the option to select Direct SQL as an option to choose SQL in the ‘Read Value for Field From:’ field instead of choosing a form or the current transaction. I would like to see this mimicked in a Table field. I’ve only needed this twice, and both times have had to identify a work-around. I don’t want to have to create an SQL view in the database every time I need to work around this. What is your input? Have you come across a situation where this would be handy (such as when you need to join two tables)? Another solution that would have worked for me in the past is if I could have chosen multiple remedy forms to pull in data to my table, using a join statement in the ‘Qualification bar’, and going through the GUI to choose which fields show up from each form, similar to when you create a join form. The reason why I don’t just create a join form to start out with is that in remedy, you cannot create a join form of two view forms, and you can only create joins of other remedy views. I don’t want to have to go out to the database, create my own non-remedy join of the tables from which the other views pull from, and then point a view form on top of that join so that I can access it in a table. Also, this would allow me to be much more flexible in which data I present in a table. Instead of having multiple tables layered on top of each other, I can just dynamically send them their own SQL qualification and use only one table, just changing the contents it displays based on the user, or based on some other options the user chooses. This could really eliminate the need for using multiple table fields in a lot of situations which I’ve seen. Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 __20060125___This posting was submitted with HTML in it___ No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.11.19/956 - Release Date: 8/16/2007 9:48 AM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Possible Table field Enhancement
It might take a bit of development effort to incorporate that in but I don't really think its impossible to allocate columns for the output generated by select. In the same way as it was done for setting fields using SQL and the use of $1$ etc from SQL column results. The table field could be built off another table like is done when using dynamic table fields, and then on selection of SQL as an option for the table to fetch the columns from, assign values for each column of the table field created. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of L. J. Head Sent: Thursday, August 16, 2007 11:48 AM To: arslist@ARSLIST.ORG Subject: Re: Possible Table field Enhancement ** First off I agree with you...it would be nice to be able to do this...but one of the complications associated with this is the fact that columns in tables use field ID's...those field ID's are used for things like colsum and such and wouldn't be available in these 'dynamic' tables. The only thing you would be able to do with these dynamic tables would be to display information...you wouldn't be able to interact with any of the data in any way because none of the columns exist and you wouldn't be able to write workflow against the nonexistant columns. I agree and have come across several instances where this type of thing would have been useful...but with my 'problem' defined...it makes the capability less interesting/useful -- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Opela, Gary L Contr OC-ALC/ITMA Sent: Thursday, August 16, 2007 6:46 AM To: arslist@ARSLIST.ORG Subject: Possible Table field Enhancement ** Well, I don’t think you can already do this, but I could see it coming in use occasionally. I would like to have the ability to set the contents of a table using Direct SQL and external(). This way I could dynamically build a query string, then use external to present it to the table field. I would like to see Direct SQL as an option in the ‘Form:’ field on the Table Property tab in the admin tool. The ‘Field on Form:’ and the ‘Field as Column’ areas would be blank, as they would just pull the list of fields from your SQL statement. You would enter your SQL (hardcoded) or the External() function in the current ‘Qualification bar’ on the Table Property tab. They do this functionality with Set Fields. You have the option to select Direct SQL as an option to choose SQL in the ‘Read Value for Field From:’ field instead of choosing a form or the current transaction. I would like to see this mimicked in a Table field. I’ve only needed this twice, and both times have had to identify a work-around. I don’t want to have to create an SQL view in the database every time I need to work around this. What is your input? Have you come across a situation where this would be handy (such as when you need to join two tables)? Another solution that would have worked for me in the past is if I could have chosen multiple remedy forms to pull in data to my table, using a join statement in the ‘Qualification bar’, and going through the GUI to choose which fields show up from each form, similar to when you create a join form. The reason why I don’t just create a join form to start out with is that in remedy, you cannot create a join form of two view forms, and you can only create joins of other remedy views. I don’t want to have to go out to the database, create my own non-remedy join of the tables from which the other views pull from, and then point a view form on top of that join so that I can access it in a table. Also, this would allow me to be much more flexible in which data I present in a table. Instead of having multiple tables layered on top of each other, I can just dynamically send them their own SQL qualification and use only one table, just changing the contents it displays based on the user, or based on some other options the user chooses. This could really eliminate the need for using multiple table fields in a lot of situations which I’ve seen. Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.11.19/956 - Release Date: 8/16/2007 9:48 AM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
