If you put a picture object on a report, that object will start out in full size. Usually I find this is much larger than I need and I have to reduce the size of the object. When you resize an image object using the sizing handles (sides and corners) you can easily change the ratio of the height to the width, which might distort the image. This ratio is called the “aspect ratio” and typically you want to keep the same ratio as in the original image.

One way to change the image size and keep the aspect ratio is to right click on the image, select “Format Graphic” and go to the “Picture” tab. There you can use the “Scaling” percentage to enlarge or reduce the height and width.  If you use the same number in both boxes the image will get bigger or smaller but will keep the aspect ratio of the original.

Today one of my colleagues showed me something he learned from one of his customers. Maybe some of you know this already but it was new to me.  If you select an image object and then hold down your “Shift” key you can change the size of the image and the “Shift” key will lock the aspect ratio.  Using the sizing handles you can make the image bigger or smaller, but the height and width will stay in proportion to each other.

One advantage of this over entering the numbers as described above, is that you can visually choose the size you want. When entering the numbers you have to exit to see the result.  This often means some trial and error to get the image to the size you want.  In testing this tonight I found that after using the “Shift” method the “Scaling” numbers in the “Picture” tab were sometimes slightly off – usually less than 1% different.  If you want them exactly the same you might still use the “Shift” method to get the size to look right visually, then go into the “Picture” tab and adjust the “Scaling” numbers so that they are exactly the same.

I had a customer this week who updated a report to read Oracle instead of SQL Server. The report was based on a command and the SQL was virtually identical. But for some reason the Oracle version would take a full 5 minutes to refresh while the SQL Server version only took a few seconds.

Once the report was run in Oracle the first time it could be refreshed using different parameters and it would only take a few seconds. I had the customer check for indexes but those had been set up to match SQL Server. I wondered if it was a data cache, but that didn’t explain why setting new parameters would be fast.

The only other thing that I could think of that was unique to the first refresh was a setting in Crystal that does a “Verify Database” on the first refresh. This usually takes a few seconds and isn’t noticeable, but as a test I turned that feature off. The first refresh was now as fast as SQL Server. Apparently, something in their environment caused the “Verify” process to take 5 minutes to complete.

If you run into something similar, go into File > Report Options and look for the check mark that says “Verify on First Refresh”.  Unless your environment is changing frequently, this doesn’t need to be checked, although in most environments you won’t notice a difference.

If you aren’t familiar with the “Verify” feature you can invoke it at any time by using the option in the database menu. This forces Crystal to poll the database for a complete list of fields for every table used by the report, including the data types.  Crystal stores this info in the report, which gives you a full field list even when you aren’t connected to the database.  Whenever fields are added, removed or their data type is changed this list needs to be updated . That is what it means to “Verify Database”.