ACCESS DB-Error: Demasiados Campos definidos

[ciberpata]

Saludos:
A lo mejor soy un poco animal, pero tengo en un formulario unos 100 y pico campos (la mayoría identifican servicios de viajes) en una DB ACCESS y todos son necesarios. El problema es que cuando proceso ese formulario para realizar las modificaciones me devuelve el error siguiente:



Microsoft OLE DB Provider for ODBC Driverserror '80004005'

[Microsoft][Controlador ODBC Microsoft Access] Demasiados campos definidos. /gestion_turishotel/ofertas/modificar_ver/actualizar_turismo_rural_result.asp, line 842


La línea 842 es la que hace el rs.update

He intentado buscar información sobre el error 80004005 pero no encuentro mi caso en las descripciones de ese error.

Lo que me mosquea es que el formulario de insercion de datos es igual al de modificaciones y por tanto tiene que añadir el mismo numero de campos a la base de datos. ¡¡Pues en las inserciones de registros no da ningún error!!. Solo es en las modificiaciones.
Evidentemente he comprobado que los campos que llegan a procesarse vienen llenos y que no hay ningún error en el nombre de un campo.

¿Podrían ustedes ayudarme?

Muchas gracias

[Muzztein]

bueno... lo mas posible es que tengas que aprender a como se modela correctamente una base de datos.

yo que tu buscaria po "formas normales" en google y me ponia a estudiar.

saludos cordiales

[verinchi]

Un error que he visto que daba algo similar a lo que decís es cuando mandas a modificar y el contenido del campo que envías contiene una coma. Por ejemplo: 10,50
Considera que el 10 y el 50 hacen referencia a dos columnas y por lo tanto dice que tenés mas campos de los que permite la tabla de la base de datos.
Otra cosa realmente no se me ocurre.

[ciberpata]

Saludos:
Creo en respuesta a Muzztein que el modelaje de la base de datos está bien hecho.
Y lo que comenta Verinchi ya lo he probado y sucede lo mismo.

De todas maneras haciendo pruebas, he visto que el problema está (parece ser) en que si se pasa de 99 campos en la tabla ya da ese error.
Con lo que estoy pensando si remodelarla o bien pasarme a MySQL si es que no tiene esas limitaciones.
El problema es que nunca he usado MySQL, pero creo por lo que he leido que sol habría que cambiar las cadenas de conexión.
Alguien puede decirme si estoy en lo correcto??
Gracias

[verinchi]

En realidad deberías tomar el consejo que te dio Muzztein y estudiar algo de normalización de datos. Eso ayuda a que no tengas una tabla con (CIEN CAMPOS???) porque es demasiado y a veces colocando tablas mas chicas relacionadas obtenés los mismos resultados.

[u_goldman]

De todas maneras haciendo pruebas, he visto que el problema está (parece ser) en que si se pasa de 99 campos en la tabla ya da ese error.

o sea que tienes mas de 99 campos en una tabla?? creo que definitivamente tendras que normalizar tu base de datos, no se trata de migrar a una herramienta superior si el diseno esta mal en principio...haz un modelado correcto de tu DB como te han aconsejado y de seguro veras cambios sustanciales

Salu2,

[AlZuwaga]

La verdad que no soy un experto en normalizacion ni mucho menos que eso, pero no sé por qué dicen que tener demaciados campos en una tabla viola de alguna manera las formas normales o que tenga una mal diseño. Ahora no las recuerdo de memoria, pero creo que ninguna de las 3 primeras FN dice algo al respecto de la cantidad de campos que se deberían tener como máximo en una tabla.

Si el motor de la base de datos (Access en este caso) no soporta semejante cantidad de campos, no hay nada que discutir. A separar en X tablas relacionadas o migrar a una BD que si lo soporte. Pero si el motor de la base de datos lo soporta... ¿por qué no hacerlo así? Puede que esté totalmente equivocado, pero a mi me parece que tener todos los campos en una tabla es más "normal" que relacionar muchas tablas que sólo contienen atributos de sólo un elemento.

[u_goldman]

Bueno master AZ, no quisiera contradecirte ni mucho menos, pero para un buen modelo de base de datos relacional(suponiendo que lo tuviera), me parece que seria una aplicacion bastante robusta, en ese caso, porque tener un motor de base de datos en Access??

La segunda de las opciones sugiere, que es una aplicacion pequena/mediana, por ese motivo una base de datos de Access es suficiente, entonces al pensar en una sola tabla, con mas de 99 campos, a mi parecer, es una base de datos totalmente disfuncional(no se si te importaria ciber poner la estructura de esta tabla, o si puedes de la base de datos) sin afan de ofender ni de crear resentimientos, a mi me parece que debe ser totalmente redudante, ese es mi argumento para apoyar la teoria que quizas ni siquiera cumple con la 1era forma normal.

En realidad la finalidad de la normalizacion o de una metodologia de analisis y diseno estructurado, en las bases de datos implica tener el mejor modelo en cuanto a performace y estructura para una aplicacion, una base de datos es eso, solamente datos dispersos por N cantidad de lados que al ser interpretados por un visor(nuestra aplicacion), nos arrojaran informacion, pero recordemos que en realidad una base de datos utopica je je, no debe tener sino 1 solo dato de su especie, y agrupando todas las especies obtendremos la informacion requerida, es por eso que se utiliza todo esto, para ocupar el minimo espacio en almacenamiento fisico, el mejor performance, y eventualmente, tener el optimo esqueleto para poder migrar nuestra aplicacion, sin necesidad de tener que hacer cambios sustanciales en nuestra base de datos, ademas de conseguir el mantenimiento mas sencillo, sabemos de antemano que cumplir con todo esto es imposible, y una base de datos se dice que esta normalizada cuando cumple al menos con la tercera forma normal, a partir de ahi, se tendria que desnormalizar para poder hacer mas sencillo nuestro acceso a los datos.

Ya me maree yo solo y eso que no es viernes pero insisto a mi parecer, 99 campos para una sola tabla en una base de datos que cumpla con algun tipo de normalizacion, me parece demasiado, y si estoy equivocado, entonces no se por que decidieron utilizar Access para esto

Salu2,

[akela]

Pues según lo que yo he estudiado de normalización, no dice que no debes tener 100 campos ni habla de el numero de campos que debes tener

pero la idea de normalizar es tener tablas pequeñas, para poder identificar rapidamente la información.

coincido con u_g no creo que esa tabla cumpla con la primera forma normal.

[Muzztein]

que alguien nombre un solo caso donde todos los datos atomicos de una sola entidad sumen 100

un caso.

[AlZuwaga]

Iniciado por Muzztein

que alguien nombre un solo caso donde todos los datos atomicos de una sola entidad sumen 100

un caso.

La población de 1 año, dos años, 3 años, ...., 100 años y mayor de 100 años que vive en una ciudad, provincia, estado o país.

No sé si es el mejor ejemplo, pero es el que ahora se me ocurre.

[Myakire]

Esto último podría ser una tabla de cuatro campos relacionada con una de Tres:

TbPoblacion (IdProvincia, IdEstado, IdPais, (FK)IdPoblación)
TbPoblacionDet ((PK)IdPoblacion, (PK)Anio, Total)

O de otra forma, da lo mismo.

Pero, igual, esa es una pregunta capciosa: "¿Qué es mejor, una tabla con pocos campos y muchos registros o una tabla con muchos campos y pocos registros?"

[franhanck]

busca formas normales de modelamiento es el mejor consejo despues deso sabras como crear una base de datos un poco ma coherente...

[franhanck]

yo se que la primera forma normal se compone de datos atomicos que no dependen de una clave

la segunda forma normal no me acuerdo muy bien pero se que por lo menos tiene que tener una clave o id que represente todos los demas campos y que atravez de esa clave se pueda obtener los datos y ademas para que una tabla este en segunda forma normal tiene que estar en primera forma

y paraque una tabla este en tercera forma normaldebe primero estar en segunda forma normal y que los campos que no pertences o que no esten directamente ligados a la clave deverian colocarse en otra con una clave que haga referencia a la tabla relacionada

carecteristicamente esta forma solo tiene a lo mas 3 campos

tambien es sierto que si te pones a normalizar todas las tablas te llenaras de un sin fin de ellas que tampoco es muy aconsejable hay pones en juego tu criteri de programador y resuelve que tablas es mas conveniente normalizarlas

[ciberpata]

Bueno, veo que la cosa está animada. Eso está bien.
Me explicaré. Siguiendo sus explicaciones he llegado a la conclusión de que mi DB no está normalizada.
Además no sabia la limitación de ACCESS donde solo se pueden actualizar 99 campos por tabla.
Dando eso por hecho quiero dejar claro que cuando tenga este trabajo acabado empezaré como tenía pensado a remodelar el site que contiene las tablas de la disputa, a fin de que ofrezca más servicios y esté hecho como Dios manda.
¿Por que me ha pasado lo de meter tantos campos en una tabla?. Pues porque como sucede muchas veces el site no iba a ser tan grande y luego crecio, crecio, crecio y crecio por cosas que generalmente no podia controlar.
Entonces como ya había mucho trabajo hecho se decidio seguir sin hacer muchos cambios en el diseño de las tablas, quedando de acuerdo en que una vez concluído se reharía bien.
Lo importante es salir al mercado porque se nos están acabando las pelas y los posibles clientes y tambien la competencia nos obliga a ponerlo en marcha ya.
Entonces ahora lo que estoy haciendo es un apaño con dos tablas relacionadas. A ver si así lo arreglo.
Lo dicho... muchas gracias a todos.

[jbastus]

Buenos días,

Tengo el mismo problema que el compañero ciberpata, una tabla de una base de datos access con 147 campos.

Por lo que leo en las distintas respuestas que se le dan, una tabla no debería nunca contener tantos campos y siendo así es que la tabla está mal modelada.

Mi tabla almacena las respuestas de un examen de 146 preguntas.
Así pues tengo una tabla con esos 146 campos + 1 id para relacionar esas respuestas con el alumno que ha realizado el examen, el centro, la fecha, ... en otra tabla.

Como debería partir esa tabla de 147 campos en otras más pequeñas?

[Muzztein]

cuando era mas joven era muy pesado :P

bueno, basicamente la cosa seria asi

Un examen puede tener muchas preguntas y esas preguntas pueden tener muchas respuestas (opciones de respuestas)
Una respuesta pertenece a una sola pregunta y una pregunta puede estar en muchos examenes

entonces te quedaria.

EXAMEN >--------PREGUTAS X EXAMEN ---------<PREGUNTAS ------------<RESPUESTAS

o algo parecido.

esperemos que te dicen los otros chicos ()

[jbastus]

entiendo tu esquema... lo veo bien... no había caído en esa estructura...
Gracias.

[jbastus]

pero pensándolo un poco mejor quizá no es la mejor solución.

Sigamos con el ejemplo del examen.

Si tengo las preguntas en una tabla y las respuestas en otra tabla, eso me obliga a que en el momento en que un usuario haga el examen (un pedazo formulario de 147 preguntas) tener que hacer un Insert por cada respuesta, es decir 147 inserts de golpe... además, como el usuario tiene la posibilidad de editar las respuestas a su examen estaría haciendo también 147 Update's de golpe... además de complicar mucho más el select en la página de editar respuestas del examen

Mi duda ahora es la siguiente:
- es mejor hacer 147 INSERTS y 147 UPDATES cada vez que se hace o edita un examen y complicar el select de la página de edición.
- o tener los 147 campos en dos tablas de 70 y pico campos cada una teniendo así únicamente 2 inserts y 2 updates?

Ven por donde voy?

Saludos.

[Muzztein]

por la primera opcion, porque asi es como se hace.

la segunda opcion que das , aparte de dar error, es impracticable, ya que si deseas agregar una pregunta a tu cuestionario, deberias adulterar la forma de la tabla.

hazme caso y leete esto http://es.wikipedia.org/wiki/Clave_for%C3%A1nea

[jbastus]

el hecho de modificar la forma de la tabla cada vez que tenga que añadir una pregunta al examen no debería ser una opción a tener en cuanta para decidir si opto por una u otra opción, el examen tiene las preguntas que tiene y no se van a añadir más. Y si por un casual se tuviera que añadir, tendría que modificar tantas otras cosas que no importa modificar también una tabla más.

Me leeré el enlace que me pasas para conocer más al respeto para otros proyectos, aunque no veo que error debería dar el hecho de tenerlo en dos tablas en este caso.

Haré algunas pruebas y si todo sale bien creo que optaré por mi segunda opción. Aunque tengo muy en cuenta que la primera es la opción correcta porque así es como se hace.

Gracias.

[Muzztein]

Si. Uno deberia hacer las aplicaciones como uno quiere y no como se debe.
ademas, el conocimiento que esta en los libros esta sobrevalorado de todas maneras.

Suerte!

[Myakire]

el hecho de modificar la forma de la tabla cada vez que tenga que añadir una pregunta al examen no debería ser una opción a tener en cuanta para decidir si opto por una u otra opción, el examen tiene las preguntas que tiene y no se van a añadir más. Y si por un casual se tuviera que añadir, tendría que modificar tantas otras cosas que no importa modificar también una tabla más.

ups!!, pues precisamente por eso se inventaron las tablas relacionadas....

La tabla de ese examen esta como en los peores tiempos del COBOL (y digo peores por que con COBOL bien estructurado se podía salvar esos detalles de cambiar el FD a medio desarollo)

La teoría tiene su razón de ser, como dice muzztein no hay que sobrevalorarla, es decir, si la teoría te dice que hay 5 formas normales, no quieras normalizar a ese extremo tu BD (yo nunca he visto una más allá de la 3 y quizá rayando la 4 en algunas tablas, solo por mencionar un ejemplo), pero tampoco hay que despreciarla, ya que si no, caeríamos en casos como en el que tu estas, donde tienes un programa rígido, que no admite escalabilidad ni modificaciones en la lógica de negocio -Si es que puedes identificar esta capa-

PD. por cierto ¿por qué revivimos este tema?

[Muzztein]

=P

Estaba siendo sarcástico.

Creo realmente que si vamos a estar haciendo caso omiso a todo lo que sale en los libros, pues vamos a estar destinados a equivocarnos una y otra vez sin aprender ni avanzar.

una cosa es el prueba y error, y otra muy distinta es pensar que uno no necesita aprender de los demas.

eso.

[Myakire]

Iniciado por Muzztein

Estaba siendo sarcástico.

jejeje, si, lo supuse a la segunda leída , pero luego pensé que quien no te conozca se lo hubiera tomado en serio y por ello puse el apunte.

Nada, nos vemos

[cynicon]

Aqui está la respuesta más sencilla:

La verdad no se nada de formalización pero ya habrá tiempo de eso, a cabo de entrar hace media hora ya que no sabia como resolver este caso, y me encuentro en una situación donde tengo que resolver el problema de guardar un cabecero con más de 200 campos, si tu caso es como el mio lo podrás hacer de esta manera.



Yo ya contaba con un cabecero con los campos que yo quería, solo que traía la tabla incluida y necesitaba el puro cabecero, cuando me puse a hacerlo solo y quize guardarlo no me dejó, y me apracio el error.


Lo que hize fue generar una consulta de creación de tabla sólo con el cabecero y listo, ya quedo ahora sí, me pondré a estudiar la formalización el el problema está solucionado


Por otro lado se me ocurre realizar el cabecero en Excel, importarlo y en ese momento definir las propiedades de cada uno, espero les sea de utilidad, saludos

[u_goldman]

Eeehh, bueno, bueno, este tema ya se revivió varias veces 'amos a cerrarlo :D


Saludos