ODBC Connection with SQL Managed Provider

  • Thread starter Thread starter Ron Fluegge
  • Start date Start date
R

Ron Fluegge

I have a Win forms application using version 1.1 that a client has installed
on a "network drive". The application connects with a SQL Server 2000
database using the Microsoft .NET Framework 1.1 Data Provider for SQL
Server.

The client's users map to the network drive and run the application from a
desktop icon that references the application on the mapped drive
(Y:\AppFolder\App.exe). In some cases, they are referencing the application
without mapping to the drive such as
\\ServerName\ShareName\AppFolder\App.exe.

The Framework 1.1, as well as all supporting files, are installed on each
user's desktop and the application "executes" just fine.

The client's problem is the "speed" of having the application start.
Apparently, it takes 1 minute for the "splash" screen to display and then
the main window follows 2 minutes later. The application EXE is 1.2 MB and
during this time it is simply getting the user's Windows identity and
authorizing the user against a table in the SQL server database. Really,
not a big chunk of code and, of course, it's blazing fast when the
application is run on the user's machine even when it goes to the database
server on the network to do the authorization -- so it appears that the SQL
Server portion (ADO.NET) is not the problem ... correct?

According to my main contact (a user and not an IT person), the client's IT
dept wants to do something with "ODBC connections" to make it "faster".
I'll be the first to admit that this is not my expertise, but is there
something that they can do with the network related to ODBC connections to
make the app download faster? I would have thought that ODBC would have no
bearing when using the Managed Providers. It's apparently something that
they can write in under an hour and make everything work ... I have to admit
that I have no idea what it is that they're planning to do.

I don't fully understand why on a corporate network it should take so long
for the app to display the "splash" screen (which is the first thing it does
so that the user authorization can proceed under the covers so to speak).

The question is: Is there anything related to Win forms/ADO.NET apps that I
can do to speed up the downloading of the application from the mapped drive
to the user's machine to run the app? The client's IT depart is supposed to
be .NET "savvy", but I'm not sure why a SQL Server Managed Provider ADO.NET
app's speed would be affected by ODBC connections...

I've Google'd everything I could thing of and have come up empty. Any
advice, references, suggestions, etc. would be greatly appreciated.

Thanks...

Ron
 
its more lilely the startup time of the .net runtime and il code instead of
sql. the odbc manager is no quicker than the odbc.

when .net runs from a network share, it runs in a different mode than if run
more a local drive. the the .net vm must startup and the il has to be jit'd.
this means 1.2 mg of il code needs to be transfered across the network, when
you run the app.

you should break the app into smaller dll's and dynamicly load them you
could get the splash screen up quicker, and only load dll's when needed.

-- bruce (sqlwork.com)
 
Thanks. I'll give it a try.

Ron

bruce barker said:
its more lilely the startup time of the .net runtime and il code instead of
sql. the odbc manager is no quicker than the odbc.

when .net runs from a network share, it runs in a different mode than if run
more a local drive. the the .net vm must startup and the il has to be jit'd.
this means 1.2 mg of il code needs to be transfered across the network, when
you run the app.

you should break the app into smaller dll's and dynamicly load them you
could get the splash screen up quicker, and only load dll's when needed.

-- bruce (sqlwork.com)
Click to expand...
 
The application is a data entry system that is "typically" loaded once (per
day at the most) and kept open until all of the data has been entered.
There's a number of data entry "forms" that need to be loaded when they go
from one "category" or data "type" to another.

So it was our intent to put a lot of the "forms" into the main app. There
are separate dlls for the datalayer, business rules, transferring the data
to another system, etc and these get called whenever their functionality is
required.

I guess the "logic" behind doing that is that we felt it would be more
"annoying" to have it be "slow" going from form to form than it would be to
have it take a minute or two during the initial load. Oh, well, speed is
relative.

FWIW, I remember having purchased an IBM PC/XT in the 1980s and thought it
was fast until I got a 486-33. Boy, was it "fast"!!! Now I have 4
networked machines at my desk that I have acquired over time and that have
respectively (1) dual Pentium Pro 150s, (2) a single ~350 MHz cpu, (3) a
single ~750 MHz cpu, and (4) a dual AMD 1600 machine. Each machine is/was
"fast" in its time!!!

I guess I suffered from Pentium envy ... kept trying to make it "bigger"
<GRIN> (been getting too many Viagra ads)

Again, Bruce, thanks for the feedback. It is very much appreciated.

Ron
 
One thing to remember is when running application from a network share, the
Code Access Security (CAS) Resticitions kick in as apps are accessed from
the Intranet zone.CAS does a Full Stack search when ever a Demand is made by
the assemblies (which is already done by System.Data.dll). This might cause
a significant performance degradation.

HTH,
Sushil.
 
I wrote an installer that grants full trust to our strong named assemblies
so that it would run from a mapped drive or a network share, but you are
correct about the overhead. The clients run this on their machines and it
grants it at the machine level under Runtime Security Policy | Machine |
Code Groups | All_Code.

The clients don't want to install the app on every user's machine. We are
looking at the "no touch" types of deployment to overcome these types of
issues.

Sushil, thanks for the reply.

Ron
 
Hi Ron,

When running a managed application from the network drive, it might be much
more slower than running from local computer. Because the CLR is checking
for permissions for security reasons. I think that why your app is so slow,
not because of the ODBC connection.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Kevin,

Thanks for the reply.

I'm not sure that I can do much more than I have already done ... given the
"design" considerations such as wanting to minimize the time between form
loads.

But, I'm open to any suggestions...

Again, thanks for the feedback. It is very much appreciated.

Ron
 
Hi Ron,

Thanks for sharing your experience with all the people here. If you have
any questions, please feel free to post them in the community.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Back
Top