Re: Follow Up...Solution (But a Bad One?)
From: DDJ (johnson_at_milehi.com)
Date: 02/24/04
- Next message: mike w.: "RE: VB using XML"
- Previous message: Geoff Callaghan: "Re: Updating a grid from a view using a Data Environment"
- In reply to: DDJ: "Re: Follow Up...More Info #2"
- Next in thread: david epsom dot com dot au: "Re: SQL Server vs. Access Over Fast Ethernet"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 24 Feb 2004 11:10:06 -0700
In our main app, we have created a "dummy" ADO connection which points
directly to the Access backend. We then create the "live" ADO connection,
which points to the Access frontend containing the linked tables. During
the Form_Activate event, we close the dummy connection, then set the dummy
connection to "Nothing".
Even though the dummy connection is used for absolutely nothing for the
short time it is around, our app starts up in 2 seconds. Appears to work
fine thereafter (since the "live" ADO connection is kept in place).
Although I think it's great that this works, there has got to be something
going on here with the Access frontend which is causing us to have to use
this "workaround".
Please let me know if you can see where we are going wrong here.
Dan
"DDJ" <johnson@milehi.com> wrote in message
news:feL_b.18$X%2.25010@news.uswest.net...
> Partial explanation for why it was starting so fast yesterday PM...
>
> We notice that if we are running a secondary exe included with our program
> when we start the main app, the main app starts in 2 seconds. The
secondary
> app is not needed to run our main app.
>
> Unlike the main app, the secondary exe connects directly to the backend
> Access database (instead of pointing to the Access frontend), using the
same
> connection string and settings as the main app uses in connecting to the
> frontend database.
>
> To summarize, if a SQL Server backend is used, startup is always fast. It
> is only when we use an Access backend that we run into problems.
>
> Hope this helps...
>
> Dan
>
> "DDJ" <johnson@milehi.com> wrote in message
> news:tFK_b.13$X%2.20791@news.uswest.net...
> > We noticed yesterday that we were opening up a number of duplicate
> > recordsets when starting the program, so we eliminated all the dupes,
and
> by
> > late yesterday afternoon we were starting the app (using an Access
backend
> > on a network share) in about 2 to 3 seconds. Thought we had the problem
> > licked...
> >
> > Today, we recompile and run the app and were back to it taking 15
seconds
> to
> > start!??
> >
> > Any ideas out there?
> >
> > Dan
> >
> > "DDJ" <johnson@milehi.com> wrote in message
> > news:4Oq_b.37$%e4.19823@news.uswest.net...
> > > Our VB6 app uses a frontend/backend database topology (using ADO 2.6).
> > The
> > > app ships with an Access frontend with all tables linked to tables in
an
> > > Access backend. Users are given the option of switching the backend
to
> > SQL
> > > Server.
> > >
> > > Average start up times for the app on a fast ethernet network with the
> > > Access backend located on a network share is around 15.2 seconds.
> Average
> > > start up times for the app when a SQL Server backend is used (on the
> same
> > > box as the network share) is 1.5 seconds. Obviously, the Access
backend
> > > option is VERY slow.
> > >
> > > Is there anything we can do with ADO connection settings, or with the
> > user's
> > > registry settings, to improve the performance when using an Access
> > backend?
> > > We expected to see some performance drop off with Access, but nowhere
> near
> > > this much!
> > >
> > > Any suggestions appreciated!
> > >
> > > Dan
> > >
> > >
> >
> >
>
>
- Next message: mike w.: "RE: VB using XML"
- Previous message: Geoff Callaghan: "Re: Updating a grid from a view using a Data Environment"
- In reply to: DDJ: "Re: Follow Up...More Info #2"
- Next in thread: david epsom dot com dot au: "Re: SQL Server vs. Access Over Fast Ethernet"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
