Conexion a BD SQL desde Cliente

[CECCO]

Hola a todos, soy nuevo en este foro
Mi Plantemiento es el siguiente, tengo una pagina en .asp convencional donde cargo un ComboBox con una tabla de vendedores. La carga de la pagina es un poco lenta estoy usando GetRows (aprox 300 registros), pero en algunos casos no se necesita la informacion que contiene el combo. (no deberia cargar esa informacion si no se va a usar)

Existe una forma para hacer esa conexion y traer los datos desde el cliente usando VbScript a traves de un boton llamando a una Subrutina sin necesidad de hacer un Reload.

Ya tengo el codigo de la carga del combo usando :
Variable = document.createElement("OPTION") y document.formulario.combo.add Variable

Muchas Gracias... Saludos.

[urjose]

No se puede.

[CECCO]

Gracias... pero hay que usar RDS pero no se nada de eso.

[AlZuwaga]

urjose, buscaste en google antes de dar esa vaga respuesta?

Yo tampoco se sobre RDS, pero acá te paso un enlace que aparentemente está bueno

Pero cuidado. Decidí bien si RDS te sirve o no antes de meterte de lleno en ello:

What deployment environments are best suited to RDS applications?

The ideal deployment environment for an RDS application is an office Intranet, Extranet, Local Area Network (LAN) or Wide Area Network (WAN) where it is possible to closely monitor server administration and to control client computer configuration, especially the client browser. RDS applications can also be accessed across the Internet and returned to clients whose users are competent to manage their computer's individual configuration. RDS applications can even be run on individual computers using Personal Web Server.



Why should I choose to use RDS?

There can be a number of reasons to choose RDS. If you want to enhance the performance of a web application whose users are forced to wait upon a server call and page refresh each time a database chore is executed, RDS can significantly speed up the process. If your server is excessively burdened by constant requests from users, RDS can reduce the server's load by transferring much of the processing work to the client computer. If your database resides on a non-Windows compatible platform and you need to introduce it into a Windows interface, RDS can be an ideal solution for cross-platform remote data access. If you want to be able to integrate the ActiveX and/or DHTML capabilities of a browser with your web application RDS can offer you a good approach to a dynamic user interface. RDS can be an excellent choice if you need to "persist" data within an application. It can also be an ideal development environment for working with disconnected, custom (crafted), and hierarchical recordsets. Or you may find that you just happen to like the ease of development that RDS offers in web applications.



Why should I choose NOT to use RDS?

There are instances where an RDS solution is either not possible or not the preferred choice. If you have a web application that requires cross-browser capability then RDS will not work, since it requires an ActiveX enabled browser. If the computer configuration of your users cannot be managed effectively and evenly with respect to the installation and maintenance of the MDAC components and/or browser security settings, an RDS solution may not be advisable. In applications where there is a very large amount of data to download to a client computer the time required to start up an RDS application may be significant, so you may want to test this download time before committing to RDS. If your users are sending and retrieving data at a low bandwidth, below 28800 bps for smaller applications, an RDS application's performance may suffer. In some instances applications that retrieve data from sources that are accessed simultaneously by numerous users are not best suited for RDS, which can handle conflicts resulting from data source updates that occur while a recordset is disconnected, but may create unnecessary headaches within an enterprise if such conflicts occur too frequently. Certain types of custom business objects that must run "in process" with other server components are not well-suited for instantiation within an RDS application. Applications created in Visual Interdev that must use its getParameters or setParameters methods will not work in RDS. On the server side RDS requires a competent administrator who understands the importance of maintaining the correct configuration settings for RDS applications to function and who can work with RDS developers to prevent "versioning" conflicts and other problems with key components.

[urjose]

Y a poco tu sabias sobre RDS daz?

Weno cada día se aprende algo nuevo, eso es chido