Talk to Ed White at OSUMC.... He'll attest to the fact that in my early years, I built some ungodly forms (one I believe has hit the limitation to the no. of fields that Remedy will allow!!!!!
I want to thank you and everyone else for the great responses! Not only did it give me some real information to which I could intelligently answer the question, but it had me ROLLING on the floor laughing!!!!!!!! Thanks again to everyone who took the time! Warren On 3/28/07, Carey Matthew Black <[EMAIL PROTECTED]> wrote:
Warren, If I can come up with an answer will you build the form? :) Well... theoretically.... The field ID space is as large as the positive range of a regular integer. :) 2,147,483,647 ( I think) So if each table field had only 1 column then you need two field ID's per table field. So the limit might be about 754305817. ( Maybe as high as 1022740773 if you break a few more rules, but likely is practically limited at that number. However if you break even more rules you could get an extra 500 table fields if the special field ID's do not product unexpected function of the tables.) So when can I expect that form with 754305867 two column table fields? (Note: I picked the most conservative number from the above. I am trying to be nice. :) I wonder how big that form definition would be. :) Here is how I got that answer: ( for the interested. :) You have a few core fields to account for... 9 by my count (1,2,3,4,5,6,7,8,15[15 for Status History]) and one VUI ID value for the default view. I do not think ARS will let you create a field ID with the same value as the VUI ID. (Just tested this on v6.3 and you can NOT have a field ID the same as any VUI ID value.) Although I think you could avoid 9 of those core fields by using a Display only form too. :) Then you would only have one field ID that you must use for the VUI ID. :) But for this example I will assume a Regular form. :) But there are also the "reserved ranges" (which you might want to avoid, but could partially violate if you decided too. :) basically 1-536870912 [ including the 10 specific ones above] So...(because we do want to be good) 2,147,483,647 - 536870912= 1610612735 total field ID's for use by a customer on a form. Yes some other ranges exist for special reasons and could add some limitations too: 1-99 : Core fields (-100) 60000-60999 : Dynamic groups ( -1000) 1000000–1999999 : Global fields ( -1000000) 3000000–3999999 : Window Scoped Global fields ( -1000000) So (because we do want to be good) that brings the number down to: 1610612735 - 100 - 1000 - 2000000 = 1508611635 ( You might actually be able to use 2000000 of those fieldID's, but I would avoid the Dynamic Groups fields. The behavior would likely be very strange if you used those.) So.. if each table field takes 2 field IDs then that leaves you with... INT(1508611635/2) = 754305817 total one column table fields you could put on a single ARS form. ( Again... theoretically. And good luck getting that form to render on the Mid-Tier. :) If you want to be bad and use the "reserved range" then you have an additional: 536870912 - 100 = 536870812 field IDs And that would be INT((1508611735+536870812)/2) = 1022741273 Total Table fields if you ignore all "special ranges" And as many as: INT((1508611735+536870812-1000)/2) =1022740773 Total Table fields if you only honor the dynamic groups "special range" And I think that is you true "final answer" for how many table fields you could add to a Regular form. (+5 more if it is a display only form. :) How you would show that many table fields... well that is your problem. :) I guess you might want to subtract two more field ID's from that set (or one table field) and keep them for a button to give the user a dialog to pick from a list of tables to show in a table field on the dialog. :) The dialog would need to return a value that other active links could do hide/show actions on to show the right table field on the local form. HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 3/28/07, Warren Baltimore <[EMAIL PROTECTED]> wrote: > ** > ARS 7.0.1 > SQL 2000 > > OK my friends, just for "kicks", here's a fun little question..... > > What are the limitations (both real and theroetical) to putting LOTS and > LOTS of Tables on a form. What would be the limitation (performance > certainly being the big one). Is there a real limit? If the tables are > only accessed via filter operations, would that make it better? > > I can't give any concrete information regarding the tables other than they > would probably be accessing seperate tables (for the most part) and would > probably only have a few fields in them. > > > > -- > Warren R. Baltimore II > Remedy Developer > UW Medicine IT Services > School of Medicine > University of Washington > Box 358220 > 1325 Fourth Ave, Suite 2000 > Seattle, WA 98101 > > The opinions expressed in this e-mail are in no way those of the University > of Washington, or the State of Washington. They are my own. > __20060125_______________________This posting was submitted > with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
-- Warren R. Baltimore II Remedy Developer UW Medicine IT Services School of Medicine University of Washington Box 358220 1325 Fourth Ave, Suite 2000 Seattle, WA 98101 The opinions expressed in this e-mail are in no way those of the University of Washington, or the State of Washington. They are my own. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"