Jason, Correct.
A user can run in Overlay mode or in Base mode (OK, an API program can specify which mode - and they default to the system setting of they don't specify which is generally the case) and the system can be configured to be running in base or overlay mode. So, the system needs to be able to run the original applications as they were if the user accessing the server is running in "base" mode and the modified application if running in "best practice" mode. This means that there are some settings that cannot be overlaid. You cannot remove or delete a unique index because if running in base mode that is expected and the data could be corrupted for that mode if the index was removed. You cannot change the datatype of a field in an overlay as that is a fundamental and inconsistent change to the field definition so we don't allow it. Think about the confusion of the same field being a character field in base mode but an attachment in the overlay. Just not practical. These restrictions are documented and are pretty obvious and basic - and there are not many. None of them affect your ability to tailor the system as needed to your needs. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jason Miller Sent: Thursday, August 22, 2013 10:44 AM To: [email protected] Subject: Re: Adding Index to Email form on v7.6.04 ** Thanks Doug for clarifying. I looked back to refresh my memory about there being a limitation on indexes in 7.6.04. What was bouncing around in the back of my mind is unique indexes cannot be modified in an overlay (pg. 131 for 7.6.04 Form and App Obj Guide). Jason On Thu, Aug 22, 2013 at 9:31 AM, Mueller, Doug <[email protected]<mailto:[email protected]>> wrote: ** Raj, I will attempt to address your various questions. 255 length limit This limit was a common DATABASE length limit for indexes in the past. Remember that in the past the max length of varchar type fields was 255 as well. That was a magic number that the database vendors used as "who could want things over that". The varchar limit as increased over the years to be in the 4000 to 8000 byte range in most databases. At the same time, the restrictions on indexes has changed over the years to allow larger field lengths. But, the length limit varies per database. The warning The warning is given so that you are aware that not all databases have the same rules and that some databases are more restrictive. If YOUR database was more restrictive, you would have gotten the warning and then an SQL error as the index was being created. The fact that you did not get the SQL error is an indication that your database accepted the index OK. Now, the warning is there because you may be creating a definition that you are going to move to another database and we are warning you that there is a chance if you do that that the definition you created here may not work in that other database. We don't want you to be caught by surprise during the import there with an error if that was the case. So, if you are only on this database and this version (this is the one you are using) you can ignore the warning. Now, on to the creating the index. When you change something in the overlay (Best Practice mode), you DO NOT change the base definition in any way. If you go and look at the base definition, it is unchanged - if it was changed, you have found a bug! So, you are getting exactly what you should expect, the definition in the overlay (Best Practice) is showing the new index and the definition in the base is NOT showing the new index. If you looked at the database, you would see the new index in place because ONE of the layers has defined it. Now, for indexes, it turns out that the index would be used regardless of which layer you were running in as a user because the DB decides on index use - but the base layer has NOT defined it and it will not show in the definition of the AR System base layer definition - even though it is there in the DB. Indexes and the addition of them has been supported since the 7.6.04 release so you should be done with what you need to do from what you described. Again, you can go to the DB level and look at the indexes on the form and see that your new index is in place if you want to double check. I hope this addresses all your questions. You followed the right path - create the overlay, update with your customization and you are good to go. In the 8.1 release, you would not have had to create the view overlay as you were not changing the UI layout or design so the work would have been even easier. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Raj Sent: Thursday, August 22, 2013 8:33 AM To: [email protected]<mailto:[email protected]> Subject: Re: Adding Index to Email form on v7.6.04 ** Thanks Jason. So, that would mean, I have to add index on the Custom to the form in Base Development Mode as well? (Sorry little confused now) LJ and Fred mentioned that I should be good to go if I just add index to the Overlay. Currently, In best practice mode I added the index to the overlay after creating form overlay. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
