Ok I know we are talking assumptions out here considering you can create about 754305817 - theoretically...
So lets assume that on the client, the client is fast enough to process about 100 cache files per second.. as it would need to process (either create or read) approximately 754305817 cache files.. So that would mean (I just calculated this for fun) the client would take about 87 days and a third of the 88th day to open that form.. Even if a client was 10 times faster and was able to process 1000 files at a time it would still mean it would take about 8 and a half days.. :-) I wonder how many days it would take to create a such a form assuming it might take about 5 minutes to create each table field... and then X amount of undeterminable time to save a form with that many objects in it :-) We might be on ARS version 10 or so by then.. Joe ----- Original Message ---- From: Carey Matthew Black <[EMAIL PROTECTED]> To: arslist@ARSLIST.ORG Sent: Wednesday, March 28, 2007 6:50:38 PM Subject: Re: Table Fields 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 ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
