[dba-SQLServer] Developer Edition v. LocalDB
John Colby
jwcolby at gmail.com
Thu Mar 31 18:50:51 CDT 2022
There are huge performance benefits to allowing sql server perform all the
queries, joins etc. It can be an order of magnitude faster.
Otoh if the data sets are small and the queries simple it won't make much
difference.
At IBM I was tasked with speeding up an app which layered a couple of dozen
tables. Reports took an hour or more doing it all in access. The users were
literally rebooting their machines because single threaded access 'locked
up'.
When I moved it into sql server it took 90 seconds or so.
Test and see.
On Thu, Mar 31, 2022, 6:49 PM Stuart McLachlan <stuart at lexacorp.com.pg>
wrote:
> If this were going to be networked, I'd disagree strongly. There is a huge
> network overhead
> if you are not using pass through queries and Access has to pull lots of
> data to apply joins,
> sorts, filters etc
>
> But since the intention is to have it all on the same machine, that is not
> really an issue and
> uing FE queries has the advantages outlined.
>
> On 31 Mar 2022 at 18:24, Daniel Waters wrote:
>
> > Hi Arthur,
> >
> > I've thought about query objects in the FE vs. SQL Views (or stored
> > procedures) in the BE. I'm going to put out a big vote to keep things
> > in the FE. This keeps things easier for you because everything is in
> > one IDE, and because the query design window in Access is easier to
> > use than the View design window in SQL. Let SQL be the place where
> > the tables are and let that be that!
> >
> > I've done this with several applications and can't see a reason to
> > change. I have used one built-in SP to let me know who was logged
> > into the database.
> >
> > Dan
> >
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
More information about the dba-SQLServer
mailing list