none
Es posible cambiar dinamicamente el origen de datos de un dataset tipado en vb.net??? RRS feed

  • Pregunta

  • Explico: Tengo una aplicación de escritorio en VB.NET que es multiusuario, por suscripción, tengo dos bases de datos en MS SQL SERVER 2008 al cual acceso remotamente a travès de la plicación, una de las bases de datos sirve para dar de alta y baja a usuarios, administra el acceso creando y asignando una base de datos a cada usuario cuando se da de alta, esta base de datos es la que quiero asignar al data set,  creo el primer usuario que llamaré "Fulanito1", le asigno la base de datos  "sqlserverbase1" para la cual ya tengo la cadena de conexión y dataset tipado.

    el problema  es cuando asigno el usuario  "Fulanito2" y le creo la base de datos  "sqlserverbase2" que tiene la misma estructura que la base de datos  "sqlserverbase1"  ( misma estructura, mismas tablas  solo es otra base de datos), quiero saber como puedo hacer que ahora mi dataset tipado trabaje con el origen de datos de la base 2.  Pienso que es posible, ya que las tablas en ambas bases de datos se llaman igual.

    En pocas palabras  cuando "Fulanito1"  inicia sesión que el dataset traiga los datos de la base1 y actualice la base 1
    cuando "Fulanito2" inicie sesión que traiga los datos de la base 2 y actualice la base 2
    y asi para cada usuario nuevo hasta  "n" usuarios que seleccione su base de datos.

    Se que del otro lado hay alguien que puede hacerlo,  ayudenmeeeeeeeeeeeeeeeeee  por favorrrrrrrrrrr 

    miércoles, 15 de abril de 2009 1:11

Respuestas

  • Primero, respecto a lo de que si lo que has hecho es correcto, la respuesta es sí: Efectivamente el connectionString se puede construir concatenando sus partes a partir de variables, y funcionan correctamente los SqlConnection construidos de esta forma. Por cierto, no sé si lo sabes, pero existe una clase que se llama SqlConnectionStringBuilder que te permite asignar como propiedades cada uno de los elementos que forman la cadena de conexión, y te devuelve la cadena ya formada. Tiene la ventaja de que garantiza que la sintaxis siempre sea correcta, incluso aunque ocurra alguna circunstancia como (por ejemplo) que la password contenga un punto y coma.

    En cuanto a lo de acceder desde Internet a un servidor Sql en una Intranet, será necesario abrir el puerto 1433 (salvo que hayas modificado la configuración del Sql Server para que use otro). La forma de abrirlo depende de cada router, y si además el router está haciendo NAT (que suele ser lo habital) habrá que configurar un NAT inverso hacia el equipo que contiene el Sql Server.

    Nota: Colabora con el foro. Marca como "respuesta" los "posts" que respondan a tu pregunta.
    • Marcado como respuesta London_cun martes, 21 de abril de 2009 4:06
    domingo, 19 de abril de 2009 17:01

Todas las respuestas

  • El dataset tipado NO tiene un origen de datos, por lo que no tiene sentido hablar de cambiarlo. El dataset no es más que un contenedor para cargar datos en memoria. Usualmente se cargan por medio de un DataAdapter (o se usa un TableAdapter, que puedes interpretar como una suma de un dataset más un dataadapter). Es en el DataAdapter donde habría que cambiar el origen de datos, y después de cambiarlo usar el dataadapter para cargar el dataset.
    Cambiar el origen de datos del dataadapter no tiene ninguna dificultad. Dentro del dataadapter hay 4 objetos command (por ejemplo, el SelectCommand es el que tiene la sentencia de selección para leer los datos desde la base de datos), y los Command tienen su correspondiente objeto Connection que puedes cambiar en cualquier momento. Por ejemplo:

    Dim ds as New MiDataSetTipado()
    Dim da as New SqlDataAdapter("Select * from MiTabla", conexion1)
    da.Fill(ds) 'Aquí cargamos el Dataset con la primera conexion
    Dim ds2 as New MiDataSetTipado()
    da.SelectCommand.Connection=conexion2
    da.Fill(ds2) 'Esta otra instancia del dataset tipado se ha cargado con otra conexion

    jueves, 16 de abril de 2009 10:31

  • Muchas gracias por tu atención, me has ayudado enormemente,  entendi perfectamente lo que me dices, puedo crear tantas instancias como quiera... es cierto, pero estuve pensando en mi problema y en realidad no necesito varias instancias ya que el usuario final solo necesita acceso a su propia base de datos  entonces una vez que razone y entendi lo que me dices analice la clase del dataset tipado y en la clase solo hace referencia a "Settings.Designer" que es donde esta la cadena de conexión,  JaJaJa .... Oh  primer porrazo en la cabeza, ahi no pude manejar variables para la cadena de conexión por lo que decidi borrarla, declarar un string en un modulo y en el formulario principal asigno el valor del string con las variables asignadas segun el usuario autenticado, que en este caso  son:   "Initial Catalog", "User ID" y "Password" y funciono, ahora la aplicación se ha vuelto una aplicacion para muchas empresas  cada una con su propia base de datos y con todos los usuarios que quiera manejar cada empresa,  todo gracias a tu aportación de conociemientos muchas gracias.

    Me gustaria  saber  si lo que hice es correcto o crees que pueda traer una consecuencia de la cual  no estoy  conciente.

    Sabes tengo otra consulta que me tiene muy intranquilo, resulta que me he montado mi propio servidor de base de datos, esta dentro de una red lan la cual  nos distribuye a todos  internet, yo crei que podia accesar a el a traves de internet pero parece que es  solo a traves de la intranet o dentro de la red lan, por lo que supongo tengo que abrir el puerto en el router   y he aqui donde surge la pregunta  porque un programa  como el ares por ejemplo si tiene acceso a traves del router si estoy escuchando todos los puertos en sql? 

    Saludos y gracias nuevamente por tu aportación
    domingo, 19 de abril de 2009 3:25
  • Primero, respecto a lo de que si lo que has hecho es correcto, la respuesta es sí: Efectivamente el connectionString se puede construir concatenando sus partes a partir de variables, y funcionan correctamente los SqlConnection construidos de esta forma. Por cierto, no sé si lo sabes, pero existe una clase que se llama SqlConnectionStringBuilder que te permite asignar como propiedades cada uno de los elementos que forman la cadena de conexión, y te devuelve la cadena ya formada. Tiene la ventaja de que garantiza que la sintaxis siempre sea correcta, incluso aunque ocurra alguna circunstancia como (por ejemplo) que la password contenga un punto y coma.

    En cuanto a lo de acceder desde Internet a un servidor Sql en una Intranet, será necesario abrir el puerto 1433 (salvo que hayas modificado la configuración del Sql Server para que use otro). La forma de abrirlo depende de cada router, y si además el router está haciendo NAT (que suele ser lo habital) habrá que configurar un NAT inverso hacia el equipo que contiene el Sql Server.

    Nota: Colabora con el foro. Marca como "respuesta" los "posts" que respondan a tu pregunta.
    • Marcado como respuesta London_cun martes, 21 de abril de 2009 4:06
    domingo, 19 de abril de 2009 17:01
  • Efectivamente,  he usado la clase SqlConnectionStringBuilder, que en realidad ahorra mucho tiempo  y codigo  recomiendo ampliamente su uso, he estado investigando y experimentando con eso del ares y ya lo entendi, escanea un puerto abierto y se cuelga de ahí, no es que lo abra realmente.  Y tambien he entendido  a la perfección que tengo que abrir el puerto  1433 en el router lo que no me queda claro es lo del NAT ¿ tienes alguna dirección donde este clara su explicación  ?

    Muchas gracias por tu ayuda

    martes, 21 de abril de 2009 4:12
  • NAT significa "Network Address Translation". Se utiliza para poder tener una red local con múltiples direcciones IP, y que todos los ordenadores puedan conectarse a Internet usando una única dirección IP pública. Las direccíones de la LAN son "privadas" (típicamente 192.168.x.x).
    Para que esto funcione, el router examina todos los paquetes IP salientes, y les cambia el remite (la dirección privada) por su dirección pública (la que tiene asignada el router en su conexión a Internet), a la vez que les cambia el puerto por uno que él tenga disponible. Cuando el ordenador que hay en Internet envía la respuesta, la envía al remite que tenía la petición, y por tanto llega al router, en un puerto conocido por éste. El router busca en una tabla interna cuál fue el equipo que pidió esa información, y hace en el paquete IP los cambios oportunos (el destinatario y el puerto pasan a ser los del equipo que pidió la información inicialmente) antes de colocar el paquete en la red local.
    Si quieres abrir un servidor interno al exterior, hay que configurar el Router para que todos los paquetes que lleguen a un puerto concreto se redirijan al puerto deseado de la dirección interna del ordenador que quieres alcanzar. Este proceso se suele conocer como "NAT inverso" ("Reverse NAT"), y la forma de configurarlo depende de cada router y viene explicada en el manual del mismo.
    martes, 21 de abril de 2009 6:56