DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 5 of 5

Thread: VB6: ADODC design time vs run time database

  1. #1
    Tim Johnson Guest

    VB6: ADODC design time vs run time database


    I'm using ADODC controls with various data-bound controls, some with grids
    (Infragistics UltraGrid), some with Text boxes and Combo boxes bound. I
    have the ADODC ConnectString and RecordSource properties set statically at
    design time to my dev DB (SQL Server 2000) and all is well (the rich dev
    environment for the grids is important). At run time, I read some variables
    from the registry and set the ConnectString and RecordSource properties programmatically
    to hit my production DB. The problem is that the ADODC controls still connect
    to the design time database at form load BEFORE I get a change to redirect
    them.

    I have over 200 data-bound controls connected to over 25 ADODC controls,
    so having dual ADODC controls and redirecting all the controls to a second
    set before building an EXE destined for production is not feasible. Surely
    there's a simple solution that I'm missing! Any assistance would be appreciated;
    I've not had much luck so far.

    Thanks,
    Tim

  2. #2
    Paul Clement Guest

    Re: VB6: ADODC design time vs run time database

    On 10 Sep 2002 11:51:20 -0700, "Tim Johnson" <johnson@epos.com> wrote:


    I'm using ADODC controls with various data-bound controls, some with grids
    (Infragistics UltraGrid), some with Text boxes and Combo boxes bound. I
    have the ADODC ConnectString and RecordSource properties set statically at
    design time to my dev DB (SQL Server 2000) and all is well (the rich dev
    environment for the grids is important). At run time, I read some variables
    from the registry and set the ConnectString and RecordSource properties programmatically
    to hit my production DB. The problem is that the ADODC controls still connect
    to the design time database at form load BEFORE I get a change to redirect
    them.

    I have over 200 data-bound controls connected to over 25 ADODC controls,
    so having dual ADODC controls and redirecting all the controls to a second
    set before building an EXE destined for production is not feasible. Surely
    there's a simple solution that I'm missing! Any assistance would be appreciated;
    I've not had much luck so far.

    What you should probably do is check to see if you're running from the IDE and then set the ADODC
    ConnectionString to the respective database *in* code. Both the ConnectionString and Recordsource
    properties of the ADODC should be blank at runtime:

    Adodc1.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\My
    Documents\db1.mdb;Persist Security Info=False"
    Adodc1.RecordSource = "Table1"
    Adodc1.Refresh

    Determine if running in IDE:

    http://support.microsoft.com/default...EN-US;q177636&


    Paul ~~~ pclement@ameritech.net
    Microsoft MVP (Visual Basic)

  3. #3
    Tim Johnson Guest

    Re: VB6: ADODC design time vs run time database


    Paul Clement <UseAdddressAtEndofMessage@swspectrum.com> wrote:
    >On 10 Sep 2002 11:51:20 -0700, "Tim Johnson" <johnson@epos.com> wrote:
    >
    >
    > I'm using ADODC controls with various data-bound controls, some with grids
    > (Infragistics UltraGrid), some with Text boxes and Combo boxes bound.

    I
    > have the ADODC ConnectString and RecordSource properties set statically

    at
    > design time to my dev DB (SQL Server 2000) and all is well (the rich dev
    > environment for the grids is important). At run time, I read some variables
    > from the registry and set the ConnectString and RecordSource properties

    programmatically
    > to hit my production DB. The problem is that the ADODC controls still

    connect
    > to the design time database at form load BEFORE I get a change to redirect
    > them.
    >
    > I have over 200 data-bound controls connected to over 25 ADODC controls,
    > so having dual ADODC controls and redirecting all the controls to a second
    > set before building an EXE destined for production is not feasible. Surely
    > there's a simple solution that I'm missing! Any assistance would be appreciated;
    > I've not had much luck so far.
    >
    >What you should probably do is check to see if you're running from the IDE

    and then
    >set the ADODC
    >ConnectionString to the respective database *in* code. Both the ConnectionString

    and
    >Recordsource
    >properties of the ADODC should be blank at runtime:
    >
    >Adodc1.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\My
    >Documents\db1.mdb;Persist Security Info=False"
    >Adodc1.RecordSource = "Table1"
    >Adodc1.Refresh
    >
    >Determine if running in IDE:
    >
    >http://support.microsoft.com/default...EN-US;q177636&
    >
    >
    >Paul ~~~ pclement@ameritech.net
    >Microsoft MVP (Visual Basic)


    Thanks for the response. You say *in* code, by that I presume you mean programmatically
    as you show. That's what I do to get to my production database. I exploit
    the design time values for these properties to utilize the rich interactive
    properties interface of the grids. The problem is that the instant you try
    to touch one of the ADODC controls to set it's properties at runtime, Form_Load
    fires which will effectively make the design-time connections for all the
    ADODC controls. It would seem that the only solution is to simply NOT take
    advantage of the design-time properties (i.e., make them all blank as you
    say). This is a serious drawback in that you can't change some global variable
    and switch from design-time to run-time connections. Ugh!


  4. #4
    Paul Clement Guest

    Re: VB6: ADODC design time vs run time database

    On 11 Sep 2002 12:34:51 -0700, "Tim Johnson" <johnson@epos.com> wrote:



    Thanks for the response. You say *in* code, by that I presume you mean programmatically
    as you show. That's what I do to get to my production database. I exploit
    the design time values for these properties to utilize the rich interactive
    properties interface of the grids. The problem is that the instant you try
    to touch one of the ADODC controls to set it's properties at runtime, Form_Load
    fires which will effectively make the design-time connections for all the
    ADODC controls. It would seem that the only solution is to simply NOT take
    advantage of the design-time properties (i.e., make them all blank as you
    say). This is a serious drawback in that you can't change some global variable
    and switch from design-time to run-time connections. Ugh!

    You should be able to connect at design-time and use the design-time functionality. You just need to
    remember to blank out the ConnectionString and Recordsource properties before compiling and set them
    programmatically in your Form's Load event.

    It's the loading of the ADODC control which causes the database engine to connect and fetch data.
    This would of course be triggered by the either the Form loading or by calling the ADODC's Refresh
    method.


    Paul ~~~ pclement@ameritech.net
    Microsoft MVP (Visual Basic)

  5. #5
    Guest

    Re: VB6: ADODC design time vs run time database


    Paul Clement <UseAdddressAtEndofMessage@swspectrum.com> wrote:
    >On 11 Sep 2002 12:34:51 -0700, "Tim Johnson" <johnson@epos.com> wrote:
    >
    >
    >
    >You should be able to connect at design-time and use the design-time functionality.
    >You just need to
    >remember to blank out the ConnectionString and Recordsource properties before

    compiling
    >and set them
    >programmatically in your Form's Load event.
    >
    >It's the loading of the ADODC control which causes the database engine to

    connect and
    >fetch data.
    >This would of course be triggered by the either the Form loading or by calling

    the ADODC's
    >Refresh
    >method.
    >
    >
    >Paul ~~~ pclement@ameritech.net
    >Microsoft MVP (Visual Basic)


    Thanks for the responses, Paul. The only problem with that approach of editing
    to point to design-time databases and then blanking out for production "compiles"
    is that I have almost THIRTY of the ADODC controls. Thanks again for your
    time.
    Regards,
    Tim

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center