Talk:Cursor (databases)
Appearance
I presume that there must be some pros with cursors as well? Senappp 21:50, 1 January 2006 (UTC)
- Yeah, there are. This article is in pretty poor shape, and I mean to add to it. Time is the limiter, as usual. -- Mikeblas 21:59, 1 January 2006 (UTC)
- I'm finally getting 'round to this, so please be patient in the interim. -- Mikeblas 00:35, 7 June 2006 (UTC)
- Great! -- Patrickdepinguin 20:37, 9 June 2006 (UTC)
- I'm finally getting 'round to this, so please be patient in the interim. -- Mikeblas 00:35, 7 June 2006 (UTC)
- Of course there are, or they wouldn't have been invented in the first place. There are (limited) situations where they make the difference between something being possible or impossible. Which is a pretty compelling advantage in my book. I've already begun improving the article, but will attempt to address this and include a real-world example or two. DigitalEnthusiast 00:54, 15 December 2006 (UTC)
- I believe that the "disadvantages" section is partly wrong and partly very imprecise. First, cursors are the only way to transfer data from a relational DBMS to a procedural application (with the exception being a SELECT INTO statement). Next, a FETCH does not imply a network round-trip at all - the DBMS client can use block fetch. Also, what are those "restrictions on SELECT statements" and what is the complex syntax? Examples would be important! After all, declaring a cursor is just prefixing a SELECT statement with DECLARE cursor-name CURSOR FOR statement. Finally, I believe that system-specific things like SQL Server's implementation based on temp tables should go into a separate (sub)section. --Stolze 13:46, 20 December 2006 (UTC)
- I'm actually not aware of any restrictions on the SELECT statement; however cursors are not the only way to get data from the db engine to the client app - the DataReader class in .net parses a TDS or Oracle network stream directly as it's sent up. As for the "complex syntax," I think that's showing up because most people who've used SQL are used to set-based operations, and not procedural coding. DigitalEnthusiast 20:58, 20 December 2006 (UTC)
- I believe that the "disadvantages" section is partly wrong and partly very imprecise. First, cursors are the only way to transfer data from a relational DBMS to a procedural application (with the exception being a SELECT INTO statement). Next, a FETCH does not imply a network round-trip at all - the DBMS client can use block fetch. Also, what are those "restrictions on SELECT statements" and what is the complex syntax? Examples would be important! After all, declaring a cursor is just prefixing a SELECT statement with DECLARE cursor-name CURSOR FOR statement. Finally, I believe that system-specific things like SQL Server's implementation based on temp tables should go into a separate (sub)section. --Stolze 13:46, 20 December 2006 (UTC)
A description of the differences between the five types of cursors would be helpful. --Sapphire Wyvern 03:13, 6 September 2006 (UTC)
Missing details
I'll address those issues once I get around to it:
- SELECT statements can always use cursors at the client side, even if there is no or just one row in the result set.
- The argument about the network round-trip is not really true, given that most systems use blocking cursors and transmit multiple rows together. That's usually implemented in the CLI/ODBC/OCI/whatever libraries.
- My experience using SQL Server 2000 using SQL Profiler ( to run a trace ) bears out what the article says about cursors. DigitalEnthusiast 00:52, 15 December 2006 (UTC)
- The WITH HOLD attribute of cursors is completely ignored.
- We should also say something about scrollability and sensitivity of cursors.
- A few more details on the usage of cursors in DELETE/UPDATE would be nice.
- Handling of cursors in X/Open XA environments (especially WITH HOLD cursors) could be explained.
--Stolze 16:51, 14 October 2006 (UTC)
Cursors make you curse
Probably not worthy of trivia, but I had a boss who said this once, and he wasn't very creative, leading me to think someone told him ... DigitalEnthusiast 19:55, 21 December 2006 (UTC)