(1) You will have to change "25" to "30" in one or more places, including SQL and possibly in H or COPY files, depending on your programming languages.
(2) This will take 5 more bytes per record and per involved index entry for CHAR and VARCHAR fields, and 10 more bytes per record and per involved index entry for GRAPHIC and VARGRAPHIC fields. For most tables or files, this is trivial.
(3) For any Crystal Reports, you should re-sync to the data-base so the user won't get a message about things having changed.
(4) Here's the only hard part: You have to look at reports, web pages, and input forms to see if more space is required for a field.
Typically, you're looking at about an hour's work for this, unless #4 gets you.
Sheldon Linker (email@example.com)
Linker Systems, Inc. (www.linkersystems.com)
It depends on the environment.
If a decent CMS (Change Management System) or cross-reference tool is in place, either one should be able to manage or report the changes that will be made. The hope would be that elements such as fields on displays are linked to the field being changed. This is where most of your time will be saved. Determine what tools have been used to manage development and use that tool (or tools).
If not, you'll need to manually look at every program and track all movements of data into and out of the changed field. This may take a very long time if the field is widely referenced, far more than an hour and perhaps many days in numerous cases.
Except to indicate that potential client accesses need attention, I don't see any reason to mention Crystal Reports nor any other particular client product. It's not clear if client processes should be included, especially if those clients are not part of normal 'Information Services' development. Processes that were developed without organizational standards of analysis, approval and acceptance perhaps should suffer from the original decisions to proceed without them.
The "forms" -- display files, printer files or any similar objects -- those do indeed represent a likely major part of the work. For example, if a display layout is crowded and there aren't sufficient spaces to hold the expansion, then significant redesign might be necessary. The number of such pieces have to be added up.
As for where to start, it depends on what is being changed. A change to a database field length is probably the change with widest impact and, therefore, with the most complexity in tracking through.
Best starting point is probably the journal for the file. That should indicate every program that has referenced the file for however far back the receivers run. It will also keep a running track as days go by in the future. If nothing else provides clear guidance, the journal will show a trail. And if journaling isn't active, then turn it on for the file while you're researching it. Follow where it leads.