>Cetin,
>
>>For UI part you might use winforms or webforms. Web service part would be done separately and needs an IIS and a proxy (or something like web matrix port implementation). If it's for intranet there isn't a need for web services IMHO.
>
>Ok. I've been thinking that IMHO was some kind of expression like LOL. But now I know I was wrong! What does it mean?

"In My Honest Opinion" - Enable acronyms from 'message view setup' drop down on upper right (don't know if a PUTM only feature).


>
>>It'd just add another layer to fake it to be called web enabled.
>
>Another layer of what? I'm sorry. You lost me here.
>

If you use web services then data should get through IIS and during travel down the wire it'd be encoded to ASCII. ASCII representation would be XML. XML data no doubt takes considerably more bytes (honestly I never liked XML getting so fat though not needed - unfortunately turned out to be the standard (really?) for data transfer).
When it's intranet you're not getting the data from a web layer really but just from another remote computer. Being remote it might be just another box in your LAN or anywhere in the world. You don't need 'web' in other words. ie:

sqlConnectString = "Data Source=205.205.57.4;Integrated Security=SSPI";

would connect to SQL server via IP (maybe with a port addition if not usinng default port) but there is no IIS in between and no costly conversion of data during travel.

>>I mean accessing say SQL server in a trusted domain just takes an IP, why would you add IIS and web service layer and its security handling.
>
>I've done this before and it is kinda slow... or probably my design was off? That's why I was thinking that using web techno wouldn't be that bad since everyone knows that a web app is slower than a rich client app. It would be like, if someone asks why is this app slow? We could always give the wev techno as a reason...
>
>But if you know of a way that I can create a client server app wherein users from europe can directly access our SQL server via IP and not suffer in speed, then definitely that would be the way I'd prefer to go.

See above. It might be slow if the connection is slow. Now add that you're using web services and also IIS in between it'd be slower. In its simple form consider XML represantation of 3 records with only firstName, lastName fields:

<customer firstName="first1" lastName="last1"/>
<customer firstName="first2" lastName="last2"/>
<customer firstName="first3" lastName="last3"/>

You see the redundancy. Data simply gets fatter. You might test this yourself. Using localhost create a web service and request 500K records from your local SQL server. Try the same w/o a web service (prefarably not in .Net - with .Net try using smaller datasets). I'm exagarating the data amount maybe but it gives the idea.

>
>I'm still kinda new to VB.NET. And I am just applying the same application design I have been using on my VB 6 apps. However, I feel that it is not the proper way to go. I still have to through the MSDN. I saw some links regarding system design .NET but I haven't really gone through it. Very busy with these killer deadlines. But I know that I have to.
>
>I'm really facinated with the power of .NET but it's just too over whelming. Patience is the key... I know.
>
>Martin

I see, I'm kinda new either. However I've been using VFP for many years and I found .Net is already slow with data (not surprising, using XML for data representation). That's why I try to avoid extra slowing factors. Probably on the long run you'd also use SQL server's replication services to get data from a nearby faster link. Good luck.
Cetin