The Daily WTF: Curious Perversions in Information Technology

Zecc · 2013-09-17 Reply Admin

eVil:
TRWTF is using capital letters at the start of all words in the title of this article, so that people like me who hail from "Reading" now automatically mispronounce the word reading like their own home town.

If whoever named the town didn't want it to be pronounced "reading" then they shouldn't have spelled it Reading.

2013-09-17 Reply Admin

The DAO waits for the caller to finish iterating the result set before closing the connection. If the caller does lengthy processing on the entity, the connection will linger for quite a while. If the caller never walks through the entire result set (intended or not), connection leaks.

IMHO, it is sensible to return a collection such that the connection can be closed/released back to pool ASAP.

IMNSHO, "Reading One Row At a Time!" is a moot point coz AFAIK most drivers read in chunks as default behaviour anyway.

dkf · 2013-09-17 Reply Admin

sob:
IMHO, it is sensible to return a collection such that the connection can be closed/released back to pool ASAP.

That depends on how much data you're pulling across to create that collection; pulling a million rows when you don't need to is expensive. (Getting the total number of rows does not require fetching all the rows first. Unless you're retarded.)

2013-09-17 Reply Admin

dkf:
sob:
IMHO, it is sensible to return a collection such that the connection can be closed/released back to pool ASAP.
That depends on how much data you're pulling across to create that collection; pulling a million rows when you don't need to is expensive. (Getting the total number of rows does not require fetching all the rows first. Unless you're retarded.)

Right, I remember that my ex-PHB once ordered me to insert half million records into production. I have to break it into chunks of several thousands each.

And I've seen morons who fail to grasp concepts such as predicated join or SELECT COUNT(*)...

2013-09-17 Reply Admin

I once used a certain application builder which worked fine with its own multiuser database but wasn't so happy when forced to connect to SQL server, since at the time it only supported one connection so you could never read just one row at a time, otherwise you would get the dreaded "Connection is busy with results for another HSTMT" error. The workaround was to configure the front end automatically download every result set ever queried in full. (I always did wonder how locking was supposed to work with multiple connections. In particular, how do you update the rows as you are reading them one at a time?)

(TDWTF decided that the background gradient on my CAPTCHA should run from black to deep red. Fortunately clicking Preview recolours it.)

Nagesh · 2013-09-17 Reply Admin

row by row = slow by slow

From Mr Tomas Kyte, the great man himself.

2013-09-17 Reply Admin

He should switch back to Btrieve. It's reading one row at a time!

We actually have a wrapper in our legacy program that simulates Btrieve in SQLServer. (Back in the days, the system was written in Btrieve and they didn't want to change all the programs that where writter to read one row at a time. Still today, where stuck with it...)

2013-09-21 Reply Admin

ANON:
JimmyCrackedCorn:
One common approach to the 'get x records from dataset' problem is to approach it from the sql select end:
select * from sometable order by name limit 20,10
This selects the 21st to the 30th rows (skip the first 20, give the next 10).

Caching 10 records (or 100, or 1000) instead of the million record dataset can be a much more efficient approach.
I think this just fetches 10 random rows and sorts them by name afterwards, because order by is done after limit.

Try the following code, the behaviour is different to what you claim, certainly in Oracle and SQL Server. Sorry it's T-SQL, too lazy to startup my Oracle VM.

SELECT TOP(10000) IDENTITY(INT, 1 ,1) AS n
INTO #test
FROM sys.columns a
CROSS JOIN sys.columns b

SELECT TOP(10) n
FROM #test
ORDER BY n DESC

SELECT TOP(10) n
FROM #test
ORDER BY n ASC

DROP TABLE #test

But...It's Reading One Row at a Time!

Leave a comment on “But...It's Reading One Row at a Time!”