Re: ODBC Connection with SQL Managed Provider
From: Ron Fluegge (rmflugge_at_swbell.net)
Date: 04/09/04
- Next message: Steven Livingstone: "Re: Using EXEC in Query"
- Previous message: Sushil Chordia: "Re: ODBC Connection with SQL Managed Provider"
- In reply to: Sushil Chordia: "Re: ODBC Connection with SQL Managed Provider"
- Next in thread: Kevin Yu [MSFT]: "Re: ODBC Connection with SQL Managed Provider"
- Reply: Kevin Yu [MSFT]: "Re: ODBC Connection with SQL Managed Provider"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 9 Apr 2004 13:07:26 -0500
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
"Sushil Chordia" <sushilc@online.microsoft.com> wrote in message
news:%23$3VgrlHEHA.700@TK2MSFTNGP09.phx.gbl...
> 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.
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Ron Fluegge" <rmflugge@swbell.net> wrote in message
> news:OmCj$hkHEHA.2924@TK2MSFTNGP09.phx.gbl...
> > 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
> >
> > "bruce barker" <nospam_brubar@safeco.com> wrote in message
> > news:%23rdH4heHEHA.252@TK2MSFTNGP12.phx.gbl...
> > > 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)
> > >
> > >
> > >
> > >
> > > "Ron Fluegge" <rmflugge@swbell.net> wrote in message
> > > news:OfjZa9aHEHA.1528@TK2MSFTNGP09.phx.gbl...
> > > > 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
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Steven Livingstone: "Re: Using EXEC in Query"
- Previous message: Sushil Chordia: "Re: ODBC Connection with SQL Managed Provider"
- In reply to: Sushil Chordia: "Re: ODBC Connection with SQL Managed Provider"
- Next in thread: Kevin Yu [MSFT]: "Re: ODBC Connection with SQL Managed Provider"
- Reply: Kevin Yu [MSFT]: "Re: ODBC Connection with SQL Managed Provider"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|