Trabajar sin DataSets

Totalmente de acuerdo, Juanjo. Además... si alguien conoce como
diseñar visualmente un datagrid (configurar sus columnas, etc) desde
un dataset que no sea tipado, que me diga cómo, porque que yo sepa no
puedes, salvo que piques el código para ello, y de lo que se trata es
de hacer las cosas lo más rápido posible y con el menos código (aunque
luego implícitamente aparezca en otro lado)

Saludos

On 4 abr, 10:44, "[Juanjo]" wrote:

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 mensajenews:

> 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

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

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

On Tue, 3 Apr 2007 14:11:08 -0400, "Pedro" wrote:

Para mi es como tu dices, Un Dataset tipeado implementa un ORM. Y si uno
se pone a revisar la cantidad de codigo auto-generado en
Dataset1.designer.cs la verdad que es dificil verle utilidad a tanto código.
Del ejemplo que cité (un form con una simple tablita de mantenimiento) vi
solo en el citado archivo, mas de mil líneas de código, sin contar los demas
archivos .CS que se auto-generan para otras cosas.

Yo una vez probé con una base de datos de tamaño medio tirando a
pequeño y me fuí a tomar un café. Cuando volví me había generado casi
300.000 lineas y el IDE iba de pena.

La aplicación terminada no debería de tener mucho más de 20.000
líneas, y ya tenía 300.000 antes de empezar a programar.

Algunos que pueden
estar de acuerdo con eso es probable que no hayan visto por dentro esos
archivos de codigo generado. Si eso es el costo de una herramienta RAD yo
prefiero hacerlo manual ;-).

Mejor no hacerlo de ninguna manera. El mejor código es el que te
ahorras.

Esperemos que la proxima version de VS que ya esta cerca traiga mejoras al
respecto porque la verdad uno se desencanta bastante.

Con LINQ las cosas deberían de mejorar bastante. Espero que sea el fin
de los ORM generadores de código.


Saludos
Alfredo

On Wed, 4 Apr 2007 00:18:15 -0400, "Rafael"
wrote:

Yo conozco C# mas a nivel academico que otra cosa pero me pregunto, no
habría alguna falta de información en eso que dicen ustedes?
Es de suponerse que a estas alturas deben haber muchas aplicaciones en
produccion en el mercado que esten hechas en C#.NET o VB.NET. Me resisto a
pensar que las cosas sean tan lentas como ustedes dicen.

Lo que pasa es que debe de haber muy poca gente que utiliza datasets
tipados en aplicaciones del mercado.

Es muy frecuente que los desarrolladores de herramientas de
programación no tengan ninguna experiencia en programación de gestión
y creen cosas inútiles.

Conozco a mucha gente que se resiste a pasar a .NET por lo malo que es
ADO.NET, y tienen bastante razón.

Sobre todo cuando en el mercado no en todas las empresas encuentra uno
equipos muy potentes para ejecutar las aplicaciones.

La excusa perfecta para vender nuevos equipos :-)


Saludos