Huge table needs to be loaded

I have to dissagree with this. If you can foresee a problem, fix it now. The example above is obviously going to be a problem and fixing it later would require extensive rework. Including major changes to how the user interacts with the app. One way for you to do this is, like you suggested, load the first two levels. Then when you get a BeforeExpand event, go to the database and populate the children of just that node. The down side is that you have to do without the + and - images that let a user know there is a reason to expand a node. You also need to figure out how to let the user know they actually did doubleclick to expand a node when there turns out to be not children. One way I have gotten around this is the past is to change the font of an empty node. You can make parents bold and empty nodes light. This is like the problem Windows Explorer has with network drives. It sometimes doesn't read the contents of a remote directory to know it has sub-directories and therefore does not show the + to let us know it is expandable. Once you doubleclick the directory though, Windows reads the contents, finds the subdirectories, and adds the child nodes. Then we have our + indicator. Some would argue this is the way Tree controls should work anyway when you are working with dynamic data. If you load the tree at the start of an app, the data may become stale. But if you are refreshing everytime a node is expanded, you get a more current view. Explorer also has issues with this sometimes on remote drives. Ever have to manually hit the Refresh button to see new files that you know should be there? If you want to employ a strategy like this to always have fresh data, you need to be concerned with expanded nodes that remain expanded for too long. The TreeView control used to have the ability to automatically collapse a node when another was expanded. This would help to to avoid that problem. But I don't see it anywhere in the .NET's version.

You seem to be trying to solve a problem that you haven't run into yet. How can you know what the solution is? You should first try it and see how long it takes. If it takes too long, find out WHY. If the time is spent populating the treeview, then you should lead the database and store it locally, populating the treeview only as necessary. If it it the database query that takes too long, you should QUERY it piece by piece. Knuth says "premature optimization is the root of all evil". Don't fix it until it's broken.