Quote Originally Posted by exterminator
Never heard or thought about this idea. I have worked on projects implemented with the multiple tiers architectures.

Got something new to hear from you but I guess this is gonna create a lot of complexities and also the usual threading related obstacles/issues would appear more frequently. Until you have a sound and clear thought about its implementation I wont go for it.

I would also like to know about the advantages that you would be extracting/exploiting with this methodology. I guess you would try getting the data access commands going while proceeding with the further non-data access related stuff.. but that hardly gonna pay you back in terms of performance..or is it? Plus the added complexities... Nah ..I wouldnt go for it too unless you convince me.
Heh I see that it sounds more complex than I wanted to make it. I am simply talking about a) a user starts an application and needs a database connection first. b) the user goes to the menu and clicks "connect".

The question is, if you had the time to code it "right" would you put the connection code in a separate thread so as to not bock the main thread until the connection completes. This way, the user can manipulate the window and the window will repaint itself while the connection is taking place. The alternative is that the main thread is block and the window just sits that unable to repaint, and unable to be manipulated by the user.

Side note: The point you bring up is kind of what a smart client would have to do. What's that called, "Disconnected Processing"?