I do that quite frequently, not for prettiness but to reduce network traffic. but my method is to calculate the number of visible rows on the form and use that to determine the maximum number of records to bring through per page. I may also display nothing initially until the user has entered a search string to find what they are looking for (even 1 character can reduce the number of records brought through by 95%). Many of my clients have tables with 1m+ records - you really don't want a form based just on that table
You need to be careful with graphs - they can take some time to render if based on a very large dataset.
I'm moving more and more towards designing UI's which have a touch screen friendly form view. In simple terms this means finger sized controls and larger font sizes which reduces the amount that can appear on screen (particularly as the typical touchscreen is smaller), so I have developed some modules that resize controls and modify the layout of the form that users can activate if a touchscreen is detected. I'm also developing some routines which work for touchscreen actions like swipes - so for example swiping a scrollbar (not using the standard offering) the form will continue to scroll and eventually slow to a stop or is stopped by the user touching the form somewhere. The acceleration/deceleration calculations are a nightmare though! still work in progress.
Other features include 'latest viewed' - a bit like the tabs at the top of IE/Chrome/Firefox and favourites so users don't have to navigate menus for frequently referenced pages.
I have also tried to make transitions more interested - for example when moving from one form to another, the old form slides off to the left (and maybe parks itself as an icon to be called back later) and the new one flies in from the right or bottom. But important this does not slow the user down. They are more interested in getting the job done than my cleverness.
Another effect is using low transparency forms to highlight sections of the underlying form.