Ejecutar un procedimiento almacenado para todos los registros de un select

Hola. Es una pregunta parecida a la que hice sobre sumar resultados en un
SP. Segun lo que he estado viendo y me han dicho, hay que hacerlo con un
cursor, porque los SP no se pueden usar en select. Podrias usar una funcion
siempre y cuando solo necesites devolver un solo valor.
Parece que con un cursor es la solucion a menos que puedas tomar la logica
del SP e incrustarla en el mismo select para eliminar el uso del SP.
Siempre leo que los cursores no son recomendables que no los usemos nunca
pero yo me pregunto : para que existen , entonces ???!!!!

"Carmen" wrote in message
news:e%

¿Es posible ejecutar un procedimiento almacenado para todos los registros

de

una select (al procedimiento almacenado hay que un campo de estos

registros)

sin necesidad de utilizar un cursor?

Muchas gracias.

Siempre leo que los cursores no son recomendables que no los usemos nunca
pero yo me pregunto : para que existen , entonces ???!!!!

Tambien existen el pico y la retro-escavadora, me inmagina que no se te
ocurriria abrir un lago usando pico verdad?. Lo mismo pasa con los cursores,
si el resultado a recorrer usando un cursor es pequeño (pocas filas) pues
claro que un cursor no dañaria mucho el performance de sql server, pero si en
cambio hablamos de miles de filas entonces el performance sufrira
considerablemente, muchas veces con el incremento del lazo se va degradando.
La mejor manera de convencerte es comparando la solucion con cursores y la
solucion basada en conjuntos.

Si puedes, lee este articulo escrito por nuestro amigo Maximiliano, aca
veras un ejemplo simple basado en dos soluciones. Veras una gran diferencia
entre el tiempo de ambas.

¿Los cursores en SqlSErver son buenos o malos?
http://www.configuracionesintegrale...p?articulo)5


Saludos,


AMB


"Alonso" wrote:

Hola. Es una pregunta parecida a la que hice sobre sumar resultados en un
SP. Segun lo que he estado viendo y me han dicho, hay que hacerlo con un
cursor, porque los SP no se pueden usar en select. Podrias usar una funcion
siempre y cuando solo necesites devolver un solo valor.
Parece que con un cursor es la solucion a menos que puedas tomar la logica
del SP e incrustarla en el mismo select para eliminar el uso del SP.
Siempre leo que los cursores no son recomendables que no los usemos nunca
pero yo me pregunto : para que existen , entonces ???!!!!

"Carmen" wrote in message
news:e%
> ¿Es posible ejecutar un procedimiento almacenado para todos los registros
de
> una select (al procedimiento almacenado hay que un campo de estos
registros)
> sin necesidad de utilizar un cursor?
>
> Muchas gracias.
>
>

ocurriria abrir un lago usando pico verdad?. Lo mismo pasa con los

cursores,

si el resultado a recorrer usando un cursor es pequeño (pocas filas) pues
claro que un cursor no dañaria mucho el performance de sql server, pero si

en

cambio hablamos de miles de filas entonces el performance sufrira

Bueno, ya eso es otra cosa. Pero no es el hecho puro y simple de decir :
"nunca usar cursores!!!" porque si no se deben usar nunca entonces MS
debería excluirlos definitivamente del TSQL.

Alonso,

Bueno, ya eso es otra cosa. Pero no es el hecho puro y simple de decir :
"nunca usar cursores!!!" porque si no se deben usar nunca entonces MS
debería excluirlos definitivamente del TSQL.

Microsoft no los ha excluido y algunas veces tambien los usa. Por ejemplo,
en la base de datos master, los siguientes procedimientos almacenados usan
cursor.

sp_adjustpublisheridentityrange
sp_bindefault
sp_bindrule
sp_change_subscription_properties
sp_check_removable
sp_cleanupdbreplication
sp_convertwebtasks
sp_copysubscription
sp_createstats
sp_databases
sp_describe_cursor
sp_describe_cursor_columns
sp_describe_cursor_tables
sp_drop_agent_profile
sp_droparticle
sp_dropdistributor
sp_droplogin
sp_dropmergearticle
sp_dropmergepublication
sp_dropmergepullsubscription
sp_dropmergesubscription
sp_droppublication
sp_droppullsubscription
sp_dropsubscriber
sp_dropsubscription
sp_expired_subscription_cleanup
sp_fulltext_catalog
sp_fulltext_database
sp_help_fulltext_catalogs_cursor
sp_help_fulltext_columns_cursor
sp_help_fulltext_tables_cursor
sp_helpconstraint
sp_helpdb
sp_helpdistpublisher
sp_helpdistributiondb
sp_helpindex
sp_helplogins
sp_helpmergearticleconflicts
sp_helpmergepullsubscription
sp_helpmergesubscription
sp_helppublication
sp_helppullsubscription
sp_helpreplicationdboption
sp_helpstats
sp_helptext
sp_mergecleanupmetadata
sp_mergemetadataretentioncleanup
sp_mergesubscription_cleanup
sp_MSaddguidindex
sp_MSadjustmergeidentity
sp_MSareallcolumnscomputed
sp_MSarticlecol
sp_MSchange_retention
sp_MScleanup_conflict
sp_MScleanup_conflict_table
sp_MScleanup_metadata
sp_MScleanupdynsnapshotvws
sp_MScleanupmergepublisher
sp_MScleanuptask
sp_MScreatebeforetable
sp_MSdbuseraccess
sp_MSdefer_check
sp_MSdelete_specifiedcontents
sp_MSdrop_6x_replication_agent
sp_MSdrop_expired_mergesubscription
sp_MSdrop_expired_subscription
sp_MSdroparticleconstraints
sp_MSdropfkreferencingarticle
sp_MSdropmergedynamicsnapshotjob
sp_MSenum_replqueues
sp_MSenum_replsqlqueues
sp_MSenumallpublications
sp_MSenumallsubscriptions
sp_MSenumpubreferences
sp_MSenumthirdpartypublicationvendornames
sp_MSexclause
sp_MSfix_6x_tasks
sp_MSfixupbeforeimagetables
sp_MSforeachdb
sp_MSforeachtable
sp_MSget_col_position
sp_MSget_synctran_commands
sp_MSgetbeforetableinsert
sp_MSgetcolumnlist
sp_MSgetviewcolumnlist
sp_MShelpalterbeforetable
sp_MShelpcreatebeforetable
sp_MShelpmergeconflictcounts
sp_MShelptranconflictcounts
sp_MSinit_replication_perfmon
sp_MSinsertbeforeimageclause
sp_MSisnonpkukupdateinconflict
sp_MSispkupdateinconflict
sp_MSload_replication_status
sp_MSloginmappings
sp_MSmakedynsnapshotvws
sp_MSmakeselectproc
sp_MSpost_auto_proc
sp_MSprep_exclusive
sp_MSpropagateschematorepubs
sp_MSpub_adjust_identity
sp_MSpublicationcleanup
sp_MSreenable_check
sp_MSreinit_failed_subscriptions
sp_MSreinit_hub
sp_MSremove_userscript
sp_MSremovedbreplication
sp_MSrepl_check_server
sp_MSrepl_FixPALRole
sp_MSreset_attach_state
sp_MSrestore_sub_merge
sp_MSrestore_sub_tran
sp_MSscript_article_view
sp_MSscript_compensating_insert
sp_MSscript_delete_pubwins
sp_MSscript_insert_pubwins
sp_MSscript_insert_statement
sp_MSscript_multirow_trigger
sp_MSscript_params
sp_MSscript_trigger_variables
sp_MSscript_update_pubwins
sp_MSscript_update_statement
sp_MSscriptdb_worker
sp_MSscriptmvastable
sp_MSscriptmvastablenci
sp_MSscriptviewproc
sp_MSSharedFixedDisk
sp_MStable_not_modifiable
sp_MSupdate_mqserver_subdb
sp_MSUpgradeConflictTable
sp_MSverifytranfilter
sp_oledb_column_constraints
sp_populateqtraninfo
sp_publication_validation
sp_refreshsubscriptions
sp_reinitmergepullsubscription
sp_reinitmergesubscription
sp_removesrvreplication
sp_replication_agent_checkup
sp_replqueuemonitor
sp_replsqlqgetrows
sp_resolve_logins
sp_script_insertforcftresolution
sp_script_reconciliation_delproc
sp_script_reconciliation_insproc
sp_script_reconciliation_xdelproc
sp_scriptdelproc
sp_scriptdynamicupdproc
sp_scriptinsproc
sp_scriptmappedupdproc
sp_scriptpkwhereclause
sp_scriptpublicationcustomprocs
sp_scriptpubwinsrefreshcursorvars
sp_scriptreconwhereclause
sp_scriptupdateparams
sp_scriptupdproc
sp_scriptxdelproc
sp_subscription_cleanup
sp_tableswc
sp_unbindefault
sp_unbindrule
sp_updatestats
sp_vupgrade_publisher
sp_vupgrade_registry
sp_vupgrade_replication
sp_vupgrade_replmsdb
sp_vupgrade_subpass
sp_vupgrade_subscription_databases
sp_vupgrade_syscol_status


AMB

"Alonso" wrote:

> ocurriria abrir un lago usando pico verdad?. Lo mismo pasa con los
cursores,
> si el resultado a recorrer usando un cursor es pequeño (pocas filas) pues
> claro que un cursor no dañaria mucho el performance de sql server, pero si
en
> cambio hablamos de miles de filas entonces el performance sufrira

Bueno, ya eso es otra cosa. Pero no es el hecho puro y simple de decir :
"nunca usar cursores!!!" porque si no se deben usar nunca entonces MS
debería excluirlos definitivamente del TSQL.

Mira, es normal encontrar gente que son "anti" una u otra técnica. A veces
irreflexivamente lo son. A veces racionalmente lo son u otras veces se
basan en una experiencia particular, no necesariamente extrapolable a otros
casos. En el caso de los cursores no es tratar de evitarlos siempre por
tratar; yo comparto lo que dice Alejandro: para un numero de elementos
pequeño, no hay problemas en armar un cursor.
Si estas hablando de, como dices en tu otro hilo, de recorrer las hijas de
una cuenta, alli no tendras problemas agregados por usar un cursor debido a
que es de esperarse que las hijas de una cuenta contable no sean tantas, a
lo sumo unas pocas decenas, o no ?.
La mejor forma de saber si algo funciona es haciendo las pruebas de lugar.




"Alonso" wrote in message
news:

> ocurriria abrir un lago usando pico verdad?. Lo mismo pasa con los
cursores,
> si el resultado a recorrer usando un cursor es pequeño (pocas filas)

pues

> claro que un cursor no dañaria mucho el performance de sql server, pero

si

en
> cambio hablamos de miles de filas entonces el performance sufrira

Bueno, ya eso es otra cosa. Pero no es el hecho puro y simple de decir :
"nunca usar cursores!!!" porque si no se deben usar nunca entonces MS
debería excluirlos definitivamente del TSQL.