Trabajar sin DataSets

On Wed, 4 Apr 2007 16:46:01 +0200, "Juan Diego Bueno"
wrote:

Bueno, 200 tablas en un solo dataset (si lo hiciste así) me parece excesivo,
no sólo para este ÍDE, sino para cualquier otro. Lo suyo sería dividirlas en
diferentes datasets. Hay un término medio entre usar un dataset para cada
tabla y usar uno para 200, pero para gustos... Y por cierto, para que el IDE
casque no hace falta gran cosa, con menos ya da problemas

Pues vaya coñazo, y además el tamaño total del código sería mayor por
que seguramente se repetirían tablas en diferentes datasets.

Creo que una vez dijiste que habías trabajado con Borland Delphi. De gente
que ha trabajado con ello, se que existe como una especie de contenedor de
datos (o algo así) donde se arrastraban los objetos de la base de datos al
estilo de los dataset. De ser así, ¿llegaste a probar a meter esas mismas
200 tablas y te iba bien el IDE?. ¿No generaba nada de código dicho
contenedor?

El Delphi genera una línea de código por cada campo persistente, lo
que pasa es que los campos persistentes solo se usan de vez en cuando
(lo mejor sería no usarlos nunca). Son bastante innecesarios si se usa
un DBMS. Estaban más pensados para los antediluvianos DBase y Paradox,
que te obligan a gestionar los datos en las aplicaciones.

También engordan las aplicaciones pero muchísimo menos. Yo intentaba
usarlos poco sobre todo por que dan rigidez a las aplicaciones. Si
cambias el esquema de la base de datos el código de la aplicación se
"descoordina" y la aplicación rompe.

El Delphi tampoco es ninguna maravilla con bases de datos. Algunas
cosas básicas se hacen muy rápido, pero como quieras salir del sota,
caballo, rey es una pesadilla.


Saludos

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 4 Apr 2007 16:46:01 +0200, "Juan Diego Bueno"
wrote:


Pues vaya coñazo, y además el tamaño total del código sería mayor por
que seguramente se repetirían tablas en diferentes datasets.

No hace falta que se repitan las tablas en diferentes datasets. En el
momento en el que necesitas datos de tal o cual tabla, tendrías que hacer
referencia al dataset en la que estuviera. Luego con databinding enlazas con
el correspondiente. Con el único con el que he tenido problemas por tener
tablas en diferentes datasets ha sido con algun informe crystal con
subinformes que esté enlazado a un dataset. Si se enlaza a varios el mismo
informe, a mi particularmente me ha dado muchos problemas.

También engordan las aplicaciones pero muchísimo menos. Yo intentaba
usarlos poco sobre todo por que dan rigidez a las aplicaciones. Si
cambias el esquema de la base de datos el código de la aplicación se
"descoordina" y la aplicación rompe.

Bueno, yo para este último problema aún no he visto una solución
satisfactoria en prácticamente ningún lenguaje o plataforma

El Delphi tampoco es ninguna maravilla con bases de datos. Algunas
cosas básicas se hacen muy rápido, pero como quieras salir del sota,
caballo, rey es una pesadilla.

Y yo con esto no trato de defender el uso de datasets tipados, de hecho, al
comenzar con ado.net no los usaba ya que empecé con fundamentos teóricos y
básicos del lenguaje. El tema es que el IDE es muy cerrado con esto, y
tienes dos opciones (resumiendo lo dicho en otros post):

1. Recurrir a datasets genéricos. Tienes menos carga de código generado, por
lo cual, a priori, más ligereza, menos consumo de recursos, etc... y más si
se ciñen exclusivamente a los datos necesarios en cada momento. También se
puede recurrir a datatables sin necesidad de usar datasets al más puro
estilo recordset o resultset de otros lenguajes. La desventaja... que el IDE
es muy quisquilloso y si para ciertas operaciones tienes que poner tu el
código. Por ejemplo, si yo quiero enlazar un grid a un datatable o a un
dataset genérico, no voy a poder ajustar las propiedades de sus columnas
visualmente y otras funcionalidades porque el IDE sólo me deja hacer esto
con datasources provenientes de datasets tipados... Puedo, obviamente,
cambiar esas propiedades a pedal mediante código, y así, ciertamente
ahorraré código, pero perderé mucho tiempo que en teoría me debería
proporcionar el IDE (es decir, no puedo cambiar la pizza de quedarme hasta
la cena por el croissant del desayuno que sale en esos anuncios tan a la
americana de Visual Studio). Y por supuesto, respecto a Crystal Reports,
olvidarme de que tire de un dataset y hacer que lo haga directamente contra
la base de datos, lo cual en principio (por mi experiencia) puede hacer que
sea el doble más lento

2. Recurrir a datasets tipados. Aquí se solucionan esos problemas del primer
punto, pero... se generan miles y miles de líneas de código de las cuales
muchas no vamos a usar. Supongo que se podría intentar borrar de los
archivos designer toda la morralla de código, pero si necesitáramos meter
otra tabla o cambiar algo, inmediatamente el IDE volvería a generar todo el
código y nos tocaría volver a borrar.

Supongo que aquí a cada cual le toca decidir que opción tomar, pero yo,
sinceramente, no veo muchas más (bueno, otra podría ser usar datareaders,
pero sería agrandar aún más la cantidad de código necesario a poner por el
desarrollador mostrada en el primer punto)

Yo no soy un experto en esto, mi experiencia en desarrollo en .net es de
apenas 3 años, pero sinceramente... no veo muchas más opciones de hacer las
cosas con .net, al menos con lo que hay ahora, y si alguien conoce algo
diferente a lo que he puesto aquí y a los ORMs, que nos ilumine

Y por cierto, Alfredo, me da que por muy bien que pueda venir LINQ estoy por
apostar que al final no va a responder a tus exigencias (sobre todo cuando
le intentes enchufar las 200 tablas xD)

Saludos

Saludos, soy un programador de Visual Foxpro que esta intentado migrar a
.NET y C# y la verdad es que esto de los manejos de datos en .NET es
decepcionante (comparado con VFP claro), disculpen la pregunta porque soy
muy nuevo en esto, pero cual seria el equivalente en C# de un cursor en VFP
obtenido mediante una consulta Select. Gracias

"Juan Diego Bueno" escribió en el mensaje
news:%

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 4 Apr 2007 16:46:01 +0200, "Juan Diego Bueno"
wrote:


Pues vaya coñazo, y además el tamaño total del código sería mayor por
que seguramente se repetirían tablas en diferentes datasets.

No hace falta que se repitan las tablas en diferentes datasets. En el
momento en el que necesitas datos de tal o cual tabla, tendrías que hacer
referencia al dataset en la que estuviera. Luego con databinding enlazas
con el correspondiente. Con el único con el que he tenido problemas por
tener tablas en diferentes datasets ha sido con algun informe crystal con
subinformes que esté enlazado a un dataset. Si se enlaza a varios el mismo
informe, a mi particularmente me ha dado muchos problemas.

También engordan las aplicaciones pero muchísimo menos. Yo intentaba
usarlos poco sobre todo por que dan rigidez a las aplicaciones. Si
cambias el esquema de la base de datos el código de la aplicación se
"descoordina" y la aplicación rompe.

Bueno, yo para este último problema aún no he visto una solución
satisfactoria en prácticamente ningún lenguaje o plataforma

El Delphi tampoco es ninguna maravilla con bases de datos. Algunas
cosas básicas se hacen muy rápido, pero como quieras salir del sota,
caballo, rey es una pesadilla.

Y yo con esto no trato de defender el uso de datasets tipados, de hecho,
al comenzar con ado.net no los usaba ya que empecé con fundamentos
teóricos y básicos del lenguaje. El tema es que el IDE es muy cerrado con
esto, y tienes dos opciones (resumiendo lo dicho en otros post):

1. Recurrir a datasets genéricos. Tienes menos carga de código generado,
por lo cual, a priori, más ligereza, menos consumo de recursos, etc... y
más si se ciñen exclusivamente a los datos necesarios en cada momento.
También se puede recurrir a datatables sin necesidad de usar datasets al
más puro estilo recordset o resultset de otros lenguajes. La desventaja...
que el IDE es muy quisquilloso y si para ciertas operaciones tienes que
poner tu el código. Por ejemplo, si yo quiero enlazar un grid a un
datatable o a un dataset genérico, no voy a poder ajustar las propiedades
de sus columnas visualmente y otras funcionalidades porque el IDE sólo me
deja hacer esto con datasources provenientes de datasets tipados... Puedo,
obviamente, cambiar esas propiedades a pedal mediante código, y así,
ciertamente ahorraré código, pero perderé mucho tiempo que en teoría me
debería proporcionar el IDE (es decir, no puedo cambiar la pizza de
quedarme hasta la cena por el croissant del desayuno que sale en esos
anuncios tan a la americana de Visual Studio). Y por supuesto, respecto a
Crystal Reports, olvidarme de que tire de un dataset y hacer que lo haga
directamente contra la base de datos, lo cual en principio (por mi
experiencia) puede hacer que sea el doble más lento

2. Recurrir a datasets tipados. Aquí se solucionan esos problemas del
primer punto, pero... se generan miles y miles de líneas de código de las
cuales muchas no vamos a usar. Supongo que se podría intentar borrar de
los archivos designer toda la morralla de código, pero si necesitáramos
meter otra tabla o cambiar algo, inmediatamente el IDE volvería a generar
todo el código y nos tocaría volver a borrar.

Supongo que aquí a cada cual le toca decidir que opción tomar, pero yo,
sinceramente, no veo muchas más (bueno, otra podría ser usar datareaders,
pero sería agrandar aún más la cantidad de código necesario a poner por el
desarrollador mostrada en el primer punto)

Yo no soy un experto en esto, mi experiencia en desarrollo en .net es de
apenas 3 años, pero sinceramente... no veo muchas más opciones de hacer
las cosas con .net, al menos con lo que hay ahora, y si alguien conoce
algo diferente a lo que he puesto aquí y a los ORMs, que nos ilumine

Y por cierto, Alfredo, me da que por muy bien que pueda venir LINQ estoy
por apostar que al final no va a responder a tus exigencias (sobre todo
cuando le intentes enchufar las 200 tablas xD)

Saludos

Muchas gracias, lo probare


"Octavio Hernandez" escribió en el mensaje
news:eW%

JJ,

Se supone que Crystal es "inteligente" :-) y transforma las fórmulas de
selección
en cláusulas WHERE cuando lo cree posible (comparaciones,
fundamentalmente).
Si ve una llamada a una función del lenguaje de Crystal, ya no la
transforma y lo
hace todo en el cliente, con el aumento de tráfico y la pérdida de
rendimiento
consiguientes.

Por ejemplo, un consejo clásico de los libros de Crystal es que, si
quieres comprobar
si el nombre de un cliente empieza con 'A' (mayúscula o minúscula)
utilices la
fórmula:

{Clientes.Nombre} = 'A' or {Clientes.Nombre´} = 'a'

en vez de:

UpperCase({Clientes.Nombre}) = 'A'

porque en este último caso se traerá toda la tabla al cliente.

A partir de CR9 (la que viene con VS 2005 es la 10) ya no se puede
modificar la sentencia SQL, solo se puede ver, mediante la opción
Crystal Reports | Base de datos | Mostrar consulta SQL del menú.
Para compensar, existe la posibilidad de "Agregar comando", que no es
más que una sentencia SQL (o llamada a proc) escrita a mano por tí
completamente.

Slds - Octavio



"[Juanjo]" escribió en el mensaje
news:

Ok, Octavio,

Yo usaba las formulas de seleccion, por eso digo que traia todos los
datos,
y no "veia" el sitio donde poner el WHERE de la sentencia (por cierto,
puedes decir donde
se pone?), de hecho, "creo" que no se puede modificar la consulta SQL a
mano en
"ver texto de la consulta" (al menos en la version del VS2005).

Un saludo.

"Octavio Hernandez" escribió en el
mensaje news:

JJ,

Cuando haces un informe en Crystal, el Crystal no hace el "where"
sobre la base de datos, si no que trae todos los datos y luego hace el
filtro.

Te puedo asegurar que *NO* tienes razón en eso. Llevo entre una cosa y
otra 12-13 años
trabajando con Crystal, y desde Crystal 4.5 eso ya funcionaba.
Simplemente, el producto
no serviría para nada si no fuera capaz de "empujar" al servidor las
condiciones de selección
en la cláusula WHERE.

Si la base de datos contra la que Crystal está trabajando es SQL (no
hablo de Btrieve, dBase
o esas otras bases "de escritorio"), con la excepción que te menciono
debajo, Crystal pasa las
condiciones a la cláusula WHERE de la sentencia SQL (lo cual se puede
ver con la opción
"Ver texto de la consulta", que está ahí desde que recuerdo - antes se
podía incluso modificar
"a mano" la sentencia SQL).

La única excepción a esta regla es cuando en tu fórmula de selección
utilizas una FORMULA
DE CRYSTAL (una fórmula escrita en uno de los lenguajes de fórmulas que
tiene Crystal).
Claro, en ese caso él tiene que traerse los registros a local para
evaluar la fórmula ahí.

Slds - Octavio



"[Juanjo]" escribió en el mensaje
news:

Buenos dias:

Soy de las personas que piensan que una cosa no es mejor que otra o
peor, si no que puede
tener cosas buenas o mejores para unas cosas y peores o no tan buenas
para otras. Con esto
que quiero decir, por ejemplo: Un DataSet tipado es mejor que hacerlo
a mano? Es posible
que si o no. Cada uno tiene su experiencia. Es cierto que si tu miras
el fichero que gener el
Dataset.designer.cs tiene 1000 lineas (mas bien es 1000 lineas por cada
consulta) es cierto,
tambien es cierto que de las 1000 lineas, la mitad de ellas son
definiciones de tipos de datos, y la
otra mitad es la comprobacion de los parametros. Que mas da que tu
compruebes los parametros
o que los comprueben por ti??? Pues habra veces que interese no
comprobarlos, no se.

Respecto a los tipos de datos fuertemente tipados, que comenta Jose
Camacho, creo que
depende tambien del motor de la base de datos. Yo con tipo de dato
fecha no he tenido problema
en guardarla en un campo fecha sobre una base de datos SQL Server, pero
cuanto he tenido
que hacer una consulta "a pelo" sobre Access he tenido que cambiar el
orden de los dias, meses y años,
y sobre VFP ademas usar la funcion date.

Crystal y Visual Studio es para comer a parte, de hecho hay un hilo
mas abajo en el cual hay
una "especie de estudio" de como hacer mejor o peor una informe.
Alguien ha pensado si es un
problema entre el Crystal y el SQL Server por ejemplo? Vuelvo a
comentar un problema que he visto
en Crystal (porque lo he probado): Cuando haces un informe en Crystal,
el Crystal no hace el "where"
sobre la base de datos, si no que trae todos los datos y luego hace el
filtro (esto lo podeis ver si mostrais
la consulta que genera el Crystal, no lo estoy inventando, y las
pruebas las hice sobre 150.000 registros)
por esto mismo, yo personalmente, prefiero pasarle al crystal un
dataset tipado con los datos, para
que no tenga que hacer el Crystal la consulta.

No quiero decir que VC#, SQL Server y Crystal sea el mejor invento
despues de las patatas fritas con
huevos ni mucho menos. Yo cuando lo necesito uso los Dataset tipados y
cuando no, hago mi consulta a
pelo. Tampoco trato de convencer a nadie. Solo digo que cada uno use lo
que mejor le venga o interese
en cada momento, en ningun sitio esta escrito que te tengas que casar
con una forma de trabajar.

Un saludo.


"Pedro" escribió en el mensaje
news:

Alguien ha visto cuando uno agrega un dataset (y sus tablas) en un
formulario visualmente la cantidad de codigo que se genera
internamente en Dataset.designer.cs?
Pregunto, es necesario todo eso para trabajar con datos. Como le hago
si no quiero trabajar con dataset o por lo menos de esa manera?

Pedro

Saludos, soy un programador de Visual Foxpro que esta intentado migrar a
.NET y C# y la verdad es que esto de los manejos de datos en .NET es
decepcionante (comparado con VFP claro), disculpen la pregunta porque soy
muy nuevo en esto, pero cual seria el equivalente en C# de un cursor en
VFP obtenido mediante una consulta Select. Gracias

El equivalente a un cursor de solo avance obtenido mediante una consulta
Select en .NET sería el DataReader, el cual se rellena mediante un Command,
pero con la salvedad de que es de sólo avance y de sólo lectura. Este además
no es desconectado, por lo cual solo trabajas con ese registro en memoria

Para simular un cursor, también podrías usar un DataTable, ya sea trayéndote
toda la tabla del tirón y moviéndote por los registros en memoria, o
rellenando el DataTable con un sólo registro de manera que tu mismo
implementes cuál es el registro a traer mediante una consulta

Saludos