Re: COUNT FOR hangs on record locking, but SQL - SELECT COUNT(*) works with no issue. Why?

Hi Stephen, Your reply doesn't help the matter in question but I'll play along.  ;-) On "real DBMS" systems like your example, shouldn't it use the header or meta-data to know the record count rather than load the whole thing into memory?  That doesn't seem right. On 10/24/2020 11:25 AM, St

Re: COUNT FOR hangs on record locking, but SQL - SELECT COUNT(*) works with no issue. Why?

Thanks, it makes sense not to reveal true identities. gl is "general ledger"? > On 24. Oct 2020, at 18:04, Stephen Russell wrote: > > glTable600 was replacing the true table name because we don't state true > identities. It is our gl transaction table and it is a beast in size. --- StripMim

Re: COUNT FOR hangs on record locking, but SQL - SELECT COUNT(*) works with no issue. Why?

glTable600 was replacing the true table name because we don't state true identities. It is our gl transaction table and it is a beast in size. On Sat, Oct 24, 2020 at 10:43 AM Christof Wollenhaupt < chris...@wollenhaupt.org> wrote: > SQL server works completely differently from FoxPro. For Sql S

Re: COUNT FOR hangs on record locking, but SQL - SELECT COUNT(*) works with no issue. Why?

SQL server works completely differently from FoxPro. For Sql Server the performance even on the same system would heavily depend on the isolation level you use, concurrent access and memory usage. I've consulted on SQL server databases projects in the close to a TB database size range where deve

Re: COUNT FOR hangs on record locking, but SQL - SELECT COUNT(*) works with no issue. Why?

I just did a count(*) from one of our biggest tables. It took 2 min to load it into memory the first time. SELECT count(*) cnt FROM [erplndb].[dbo].[glTable600] cnt 138,371,855 The second time I run this it only takes .03 seconds. The size of the table and index is a mere 364 gigs today.