BOND CONTROLS vs. UNBOND CONTROLS


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 13 of 13

Thread: BOND CONTROLS vs. UNBOND CONTROLS

  1. #1
    saly Guest

    BOND CONTROLS vs. UNBOND CONTROLS


    Hi every body
    what is the differences between BOND CONTROLS & UNBOND CONTROLS?

    thank you very much

  2. #2
    Arthur Wood Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS


    "saly" <iamsmahd@yahoo.com> wrote:
    >
    >Hi every body
    >what is the differences between BOND CONTROLS & UNBOND CONTROLS?
    >
    >thank you very much

    BOUND (not BOND) controls are linked DIRECTLY to a field in a table in your
    database. That means that the data displayed in the control COMES directly
    from the corresponding field in the bound table, without any programming
    required. And when a change is made to the data displayed in that control,
    the change is automatically made to the corresponding data in the bound field
    in the table in the database, again with no programming require.

    With UNBOUND controls, the movement of data TO and FROM the database is comnpletely
    controlled by the program that you write.

    Personnaly, I NEVER use BOUND controls for ANY PURPOSE, whatsoever. I find
    that with a BOIUND control, the movement of data between the application
    and the database happens in ways that I do not want to have happen. In particualr,
    I want to control such eventsd as DATA VALIDATION, and cponsistency checking,
    BEFORE the database is updated. I want to guarnatee that the data to be
    stored in the table is VALID, and to be able to allow the user to either
    corrent any errors, or completely abort the transaction, BEFORE any changes
    are made in the database.

    BOUND controls APPEAR to be a very easy way to get data into and out of your
    database, but that appearnce is VERY VERY deceptive. You will very quickly
    discover that there will be some set of circumstances that arise in the processing
    of your program, that CANNOT be accomplished because you are using BOUND
    controls. It will be MUCH easier, in the long run, to control the data and
    its disply with your program, and tpo NOT rely on the use of BOUND controls.

    Arthur Wood

  3. #3
    Steve P Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS


    Bound controls cover instances where you place a DataControl on a form, then
    link controls (text boxes, etc.) to that Data Control using the DataSource
    property.

    Unbound controls are where you transfer data to and from the GUI programatically,
    usually using code-based recordset objects and self-defined entity classes.

    If you want to develop good, structured, and logically/physically tiered
    programs, I strongly recommend adopting Unbound programming practices. Some
    of the shortcomings of the Bound approach include:

    - Bad for n-tier development where your GUI is supposed to be independent
    and oblivious to the database structure. Bound forms link your GUI directly
    to the data, and make your GUI dependent on the table/view/query layout.

    - Does not support post-entry validation. Lets say for example that you have
    a text field that needs to be populated and cannot accept an empty string.
    In the GUI with Bound controls it will force the user to enter a value in
    that text entry box before letting them leave the control. This can often
    be irritating to the user if they want to defer entering a value in order
    to check, or change another value first. Their only option is to enter an
    potentially invalid value just to move to another selection which can lead
    to data entry errors. Post-entry validation would allow the user to enter
    in the values in any order without restrictions, then validate all values
    at once before they perform an action such as saving.

    - Keeps a Recordset cursor open for the duration of the form's life. With
    Bound controls a recordset is left open while the form is loaded. This can
    cause issues with record locking, as well as leave some databases vulnerable
    to corruption in the event that your application crashes or you use the Stop
    button from within the VB development environment while the form is loaded.
    Using unbound recordsets you can open the recordset, populate your objects,
    and close the recordset then use the objects to populate your forms safely.
    This leaves the records "free" for other users, however this means you will
    need to code for change collision detection. (Where if you make changes to
    your objects, you need to check to see if the database has been altered since
    the time that the data was retrieved and make accommodation for this.)

    Steve.

    "saly" <iamsmahd@yahoo.com> wrote:
    >
    >Hi every body
    >what is the differences between BOND CONTROLS & UNBOND CONTROLS?
    >
    >thank you very much



  4. #4
    Jason hawryluk Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS

    I am soory all but i do not agree. Comments inline..

    "Steve P" <stevepyn@hotmail.com> a écrit dans le message news:
    3e356cc9$1@tnews.web.devx.com...
    >
    > Bound controls cover instances where you place a DataControl on a form,

    then
    > link controls (text boxes, etc.) to that Data Control using the DataSource
    > property.


    You could also use a data source class. Bound in my mind means a control(s)
    that are bound to any datasource whether it be a datacontrol, datasource
    class or any other data object. Perhaps the binding mechinisime is not the
    same.

    >
    > Unbound controls are where you transfer data to and from the GUI

    programatically,
    > usually using code-based recordset objects and self-defined entity

    classes.

    (self-defined entity classes) Maintenance work change a struc in the db and
    change the classes and re deploy. Also limited what about user defined
    fields??

    > If you want to develop good, structured, and logically/physically tiered
    > programs, I strongly recommend adopting Unbound programming practices.

    Some
    > of the shortcomings of the Bound approach include:
    >
    > - Bad for n-tier development where your GUI is supposed to be independent
    > and oblivious to the database structure. Bound forms link your GUI

    directly
    > to the data, and make your GUI dependent on the table/view/query layout.


    If you use Datasource classes in a seperate data dll gui is independent. We
    use the tag in the control to help with the db mapping. This tag is added
    dynamicly. Encapsulation is saved.

    > - Does not support post-entry validation. Lets say for example that you

    have
    > a text field that needs to be populated and cannot accept an empty string.


    Simply not true, useing a data source class and a recordset dimed withevents
    you have complete control over validation. as well as formatting befor
    saves.

    > In the GUI with Bound controls it will force the user to enter a value in
    > that text entry box before letting them leave the control.


    Not true. Datasource class

    > This can often
    > be irritating to the user if they want to defer entering a value in order
    > to check, or change another value first. Their only option is to enter an
    > potentially invalid value just to move to another selection which can lead
    > to data entry errors.
    > Post-entry validation would allow the user to enter
    > in the values in any order without restrictions, then validate all values
    > at once before they perform an action such as saving.


    Datasource class

    > - Keeps a Recordset cursor open for the duration of the form's life.


    No true, Datasource class with disconnected recordset.

    >With
    > Bound controls a recordset is left open while the form is loaded. This can
    > cause issues with record locking, as well as leave some databases

    vulnerable
    > to corruption in the event that your application crashes or you use the

    Stop
    > button from within the VB development environment while the form is

    loaded.

    > Using unbound recordsets you can open the recordset, populate your

    objects,
    > and close the recordset then use the objects to populate your forms

    safely.

    Creating a data object for each table causes maintenance problems. (Simply
    my view)

    > This leaves the records "free" for other users, however this means you

    will
    > need to code for change collision detection. (Where if you make changes to
    > your objects, you need to check to see if the database has been altered

    since
    > the time that the data was retrieved and make accommodation for this.)


    We use usercontrols that are bound to datasource classes using the
    (Bindingcollection) that give all the benifits of validation,
    locking,control over saves deletes, updates. Useing a disconnected recordset
    will unlock the db and release the connection cursor. Using withevnts will
    allow complete control and give the developer the benifit of a recordset.
    Very little coding. We keep these classes in a seperate dll, this gives us
    tier support and scalability. Recordlocking is controled by the recordset
    automaticly (no extra codeing is required except to trap the error).
    Populating an object for each entity (as you suggest) in the db is process
    consuming.

    Very easy code resuse as we have over 30+ controls and still counting and
    use 2 data source classes. One for list views and one for modifiable views.
    Allowing filters,sorts,virtual loading etc. In the same dll we have a gen
    sql class that creates a sql statement for the data source classes to
    consume. We also have a Command Execute class for all other needs.
    We have a db catalog object that is loaded at runtime to give info on any
    table of field. Avoiding round trips to the server.
    I could go on and on...

    Just my thoughts...

    >
    > Steve.
    >
    > "saly" <iamsmahd@yahoo.com> wrote:
    > >
    > >Hi every body
    > >what is the differences between BOND CONTROLS & UNBOND CONTROLS?
    > >
    > >thank you very much

    >




  5. #5
    ralph Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS


    "Jason hawryluk" <jh@3gcomm.fr> wrote:
    >I am soory all but i do not agree. Comments inline..
    >
    >"Steve P" <stevepyn@hotmail.com> a écrit dans le message news:
    >3e356cc9$1@tnews.web.devx.com...
    >>
    >> Bound controls cover instances where you place a DataControl on a form,

    >then
    >> link controls (text boxes, etc.) to that Data Control using the DataSource
    >> property.

    >
    >You could also use a data source class. Bound in my mind means a control(s)
    >that are bound to any datasource whether it be a datacontrol, datasource
    >class or any other data object. Perhaps the binding mechinisime is not the
    >same.
    >
    >>
    >> Unbound controls are where you transfer data to and from the GUI

    >programatically,
    >> usually using code-based recordset objects and self-defined entity

    >classes.
    >
    >(self-defined entity classes) Maintenance work change a struc in the db

    and
    >change the classes and re deploy. Also limited what about user defined
    >fields??
    >
    >> If you want to develop good, structured, and logically/physically tiered
    >> programs, I strongly recommend adopting Unbound programming practices.

    >Some
    >> of the shortcomings of the Bound approach include:
    >>
    >> - Bad for n-tier development where your GUI is supposed to be independent
    >> and oblivious to the database structure. Bound forms link your GUI

    >directly
    >> to the data, and make your GUI dependent on the table/view/query layout.

    >
    >If you use Datasource classes in a seperate data dll gui is independent.

    We
    >use the tag in the control to help with the db mapping. This tag is added
    >dynamicly. Encapsulation is saved.
    >
    >> - Does not support post-entry validation. Lets say for example that you

    >have
    >> a text field that needs to be populated and cannot accept an empty string.

    >
    >Simply not true, useing a data source class and a recordset dimed withevents
    >you have complete control over validation. as well as formatting befor
    >saves.
    >
    >> In the GUI with Bound controls it will force the user to enter a value

    in
    >> that text entry box before letting them leave the control.

    >
    >Not true. Datasource class
    >
    >> This can often
    >> be irritating to the user if they want to defer entering a value in order
    >> to check, or change another value first. Their only option is to enter

    an
    >> potentially invalid value just to move to another selection which can

    lead
    >> to data entry errors.
    >> Post-entry validation would allow the user to enter
    >> in the values in any order without restrictions, then validate all values
    >> at once before they perform an action such as saving.

    >
    >Datasource class
    >
    >> - Keeps a Recordset cursor open for the duration of the form's life.

    >
    >No true, Datasource class with disconnected recordset.
    >
    >>With
    >> Bound controls a recordset is left open while the form is loaded. This

    can
    >> cause issues with record locking, as well as leave some databases

    >vulnerable
    >> to corruption in the event that your application crashes or you use the

    >Stop
    >> button from within the VB development environment while the form is

    >loaded.
    >
    >> Using unbound recordsets you can open the recordset, populate your

    >objects,
    >> and close the recordset then use the objects to populate your forms

    >safely.
    >
    >Creating a data object for each table causes maintenance problems. (Simply
    >my view)
    >
    >> This leaves the records "free" for other users, however this means you

    >will
    >> need to code for change collision detection. (Where if you make changes

    to
    >> your objects, you need to check to see if the database has been altered

    >since
    >> the time that the data was retrieved and make accommodation for this.)

    >
    >We use usercontrols that are bound to datasource classes using the
    >(Bindingcollection) that give all the benifits of validation,
    >locking,control over saves deletes, updates. Useing a disconnected recordset
    >will unlock the db and release the connection cursor. Using withevnts will
    >allow complete control and give the developer the benifit of a recordset.
    >Very little coding. We keep these classes in a seperate dll, this gives

    us
    >tier support and scalability. Recordlocking is controled by the recordset
    >automaticly (no extra codeing is required except to trap the error).
    >Populating an object for each entity (as you suggest) in the db is process
    >consuming.
    >
    >Very easy code resuse as we have over 30+ controls and still counting and
    >use 2 data source classes. One for list views and one for modifiable views.
    >Allowing filters,sorts,virtual loading etc. In the same dll we have a gen
    >sql class that creates a sql statement for the data source classes to
    >consume. We also have a Command Execute class for all other needs.
    >We have a db catalog object that is loaded at runtime to give info on any
    >table of field. Avoiding round trips to the server.
    >I could go on and on...
    >
    >Just my thoughts...
    >
    >>
    >> Steve.
    >>
    >> "saly" <iamsmahd@yahoo.com> wrote:
    >> >
    >> >Hi every body
    >> >what is the differences between BOND CONTROLS & UNBOND CONTROLS?
    >> >
    >> >thank you very much

    >>

    >


    Very good Jason.

    I was itching to add my "two cents" but chickened out.

    Unfortunately I discovered "Data Aware" classes and "ADO Events" too late
    (about a year ago and now it is time to move on to .NET <g>).

    But this last year has been great. The combination of UserControls, "DataSource"
    attributes, and Events has led to amazingly simple code (write once and forget),
    seemlessly tiered, and for very robust data handling. When I think back to
    all that mindless repetitive stuff I wrote for years...

    -ralph


  6. #6
    Steve P. Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS


    There are simple, elegant solutions to developing well structured code with
    any tool available if you do the research on how to use the tool correctly.
    (Even with more tempermental topics like GoTo My initial response may have
    sounded a bit harsh like "there is no way you can write well structured code
    with data bound controls." which of course is not true.

    However,

    9 out of 10, or maybe 95 out of 100 people that ask about bound controls
    are bound(what a pun to be thinking of linking form controls to data controls
    on the GUI.

    Now I won't have any eggs to throw in people's faces unless they'd care to
    argue that using data "controls" linked directly to the DB on forms with
    bound entry controls is a "good" idea... :]

    The disconnected recordset idea with a Data class was an interesting comment.
    But I am interested to hear how to support post-edit validation. (I.e. Don't
    do any validation until the user hits "Save")I understand that you can intercept
    the event from the RS before the field changes, however if the field in the
    RS is marked Not Null and the user starts entering a value then backs out
    of the control, how do you avoid the situation that the RS is going to complain
    about an empty value? (I supose ignoring the error would work...) Can the
    bound control release focus with an invalid value in the control?

    The only issue I've run across while using disconnected recordsets (not bound,
    but wrapped) was trying to manage the reconnect and update. (Batch Updates)
    Many of the projects I currently work on I don't have the luxury of defining
    the schema I'm talking to, and the presentation of data is typically merged
    from a number of data tables. This results in quite a few joins, somthing
    that the disconnected recordsets never seem to want to update. :\ Well that
    and the MS Provider for Oracle not storing row IDs in the cursors, but if
    I recall right, the joins caused issues with batch updates using the Oracle
    provider.

    Steve.

    "Jason hawryluk" <jh@3gcomm.fr> wrote:
    >I am soory all but i do not agree. Comments inline..
    >
    >"Steve P" <stevepyn@hotmail.com> a 飲it dans le message news:
    >3e356cc9$1@tnews.web.devx.com...
    >>
    >> Bound controls cover instances where you place a DataControl on a form,

    >then
    >> link controls (text boxes, etc.) to that Data Control using the DataSource
    >> property.

    >
    >You could also use a data source class. Bound in my mind means a control(s)
    >that are bound to any datasource whether it be a datacontrol, datasource
    >class or any other data object. Perhaps the binding mechinisime is not the
    >same.
    >
    >>
    >> Unbound controls are where you transfer data to and from the GUI

    >programatically,
    >> usually using code-based recordset objects and self-defined entity

    >classes.
    >
    >(self-defined entity classes) Maintenance work change a struc in the db

    and
    >change the classes and re deploy. Also limited what about user defined
    >fields??
    >
    >> If you want to develop good, structured, and logically/physically tiered
    >> programs, I strongly recommend adopting Unbound programming practices.

    >Some
    >> of the shortcomings of the Bound approach include:
    >>
    >> - Bad for n-tier development where your GUI is supposed to be independent
    >> and oblivious to the database structure. Bound forms link your GUI

    >directly
    >> to the data, and make your GUI dependent on the table/view/query layout.

    >
    >If you use Datasource classes in a seperate data dll gui is independent.

    We
    >use the tag in the control to help with the db mapping. This tag is added
    >dynamicly. Encapsulation is saved.
    >
    >> - Does not support post-entry validation. Lets say for example that you

    >have
    >> a text field that needs to be populated and cannot accept an empty string.

    >
    >Simply not true, useing a data source class and a recordset dimed withevents
    >you have complete control over validation. as well as formatting befor
    >saves.
    >
    >> In the GUI with Bound controls it will force the user to enter a value

    in
    >> that text entry box before letting them leave the control.

    >
    >Not true. Datasource class
    >
    >> This can often
    >> be irritating to the user if they want to defer entering a value in order
    >> to check, or change another value first. Their only option is to enter

    an
    >> potentially invalid value just to move to another selection which can

    lead
    >> to data entry errors.
    >> Post-entry validation would allow the user to enter
    >> in the values in any order without restrictions, then validate all values
    >> at once before they perform an action such as saving.

    >
    >Datasource class
    >
    >> - Keeps a Recordset cursor open for the duration of the form's life.

    >
    >No true, Datasource class with disconnected recordset.
    >
    >>With
    >> Bound controls a recordset is left open while the form is loaded. This

    can
    >> cause issues with record locking, as well as leave some databases

    >vulnerable
    >> to corruption in the event that your application crashes or you use the

    >Stop
    >> button from within the VB development environment while the form is

    >loaded.
    >
    >> Using unbound recordsets you can open the recordset, populate your

    >objects,
    >> and close the recordset then use the objects to populate your forms

    >safely.
    >
    >Creating a data object for each table causes maintenance problems. (Simply
    >my view)
    >
    >> This leaves the records "free" for other users, however this means you

    >will
    >> need to code for change collision detection. (Where if you make changes

    to
    >> your objects, you need to check to see if the database has been altered

    >since
    >> the time that the data was retrieved and make accommodation for this.)

    >
    >We use usercontrols that are bound to datasource classes using the
    >(Bindingcollection) that give all the benifits of validation,
    >locking,control over saves deletes, updates. Useing a disconnected recordset
    >will unlock the db and release the connection cursor. Using withevnts will
    >allow complete control and give the developer the benifit of a recordset.
    >Very little coding. We keep these classes in a seperate dll, this gives

    us
    >tier support and scalability. Recordlocking is controled by the recordset
    >automaticly (no extra codeing is required except to trap the error).
    >Populating an object for each entity (as you suggest) in the db is process
    >consuming.
    >
    >Very easy code resuse as we have over 30+ controls and still counting and
    >use 2 data source classes. One for list views and one for modifiable views.
    >Allowing filters,sorts,virtual loading etc. In the same dll we have a gen
    >sql class that creates a sql statement for the data source classes to
    >consume. We also have a Command Execute class for all other needs.
    >We have a db catalog object that is loaded at runtime to give info on any
    >table of field. Avoiding round trips to the server.
    >I could go on and on...
    >
    >Just my thoughts...
    >
    >>
    >> Steve.
    >>
    >> "saly" <iamsmahd@yahoo.com> wrote:
    >> >
    >> >Hi every body
    >> >what is the differences between BOND CONTROLS & UNBOND CONTROLS?
    >> >
    >> >thank you very much

    >>

    >
    >



  7. #7
    Chris Hylton Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS


    I think the arguments here (and just above by both Steve and Arthur) are very
    valid concerns to be addressed...but with disconnected recordset capability
    in ADO, don't discount the benefit of bound controls for eliminating the
    need for coding and the possiblity of having to recode your app when you
    change something in the database...not that you don't have to do that 9 times
    out of 10 anyway...

    But...I didn't used to believe in bound controls either until the disconnected
    world arose...now that's all I use (accept in rare situations where unbound
    makes more sense)...

    Anyway...I'm a big believer in hitting non-updateable views rather than the
    original tables anyway...I never expose my actual tables if I don't have
    to...and in Access, this doesn't always work b/c queries are all you have
    and Jet does support update through the query and you can't turn that off...

    But...regardless...the point is the same...if you read your data from a non-updateble
    view or a table, you can disconnect and update the local recordset all you
    want...and then pass back updates either through stored procs (sql or oracle)
    or action queries (access) w/ parameters...if you want, you can always reconnect
    the recordset and update batch, but then you are back into the issues you
    guys mentioned above...

    You also don't have to use a datacontrol...which I hate...just bind directly
    to the recordset...granted, you have to have a block of code do this rather
    than setting a property at design-time, but maybe that is just my old 'bound
    controls sucks' mentality that keeps me from using a datacontrol...dunno...I
    just don't use them...just a simple Set textbox.Datasource = rs is all I
    use to do the bind process...the datafield is set in the property window,
    or by code also.

    Just my 2 cents...

    Chris

    "Steve P." <stevepyn@hotmail.com> wrote:
    >
    >There are simple, elegant solutions to developing well structured code with
    >any tool available if you do the research on how to use the tool correctly.
    >(Even with more tempermental topics like GoTo My initial response may

    have
    >sounded a bit harsh like "there is no way you can write well structured

    code
    >with data bound controls." which of course is not true.
    >
    >However,
    >
    >9 out of 10, or maybe 95 out of 100 people that ask about bound controls
    >are bound(what a pun to be thinking of linking form controls to data controls
    >on the GUI.
    >
    >Now I won't have any eggs to throw in people's faces unless they'd care

    to
    >argue that using data "controls" linked directly to the DB on forms with
    >bound entry controls is a "good" idea... :]
    >
    >The disconnected recordset idea with a Data class was an interesting comment.
    >But I am interested to hear how to support post-edit validation. (I.e. Don't
    >do any validation until the user hits "Save")I understand that you can intercept
    >the event from the RS before the field changes, however if the field in

    the
    >RS is marked Not Null and the user starts entering a value then backs out
    >of the control, how do you avoid the situation that the RS is going to complain
    >about an empty value? (I supose ignoring the error would work...) Can the
    >bound control release focus with an invalid value in the control?
    >
    >The only issue I've run across while using disconnected recordsets (not

    bound,
    >but wrapped) was trying to manage the reconnect and update. (Batch Updates)
    >Many of the projects I currently work on I don't have the luxury of defining
    >the schema I'm talking to, and the presentation of data is typically merged
    >from a number of data tables. This results in quite a few joins, somthing
    >that the disconnected recordsets never seem to want to update. :\ Well that
    >and the MS Provider for Oracle not storing row IDs in the cursors, but if
    >I recall right, the joins caused issues with batch updates using the Oracle
    >provider.
    >
    >Steve.
    >
    >"Jason hawryluk" <jh@3gcomm.fr> wrote:
    >>I am soory all but i do not agree. Comments inline..
    >>
    >>"Steve P" <stevepyn@hotmail.com> a 飲it dans le message news:
    >>3e356cc9$1@tnews.web.devx.com...
    >>>
    >>> Bound controls cover instances where you place a DataControl on a form,

    >>then
    >>> link controls (text boxes, etc.) to that Data Control using the DataSource
    >>> property.

    >>
    >>You could also use a data source class. Bound in my mind means a control(s)
    >>that are bound to any datasource whether it be a datacontrol, datasource
    >>class or any other data object. Perhaps the binding mechinisime is not

    the
    >>same.
    >>
    >>>
    >>> Unbound controls are where you transfer data to and from the GUI

    >>programatically,
    >>> usually using code-based recordset objects and self-defined entity

    >>classes.
    >>
    >>(self-defined entity classes) Maintenance work change a struc in the db

    >and
    >>change the classes and re deploy. Also limited what about user defined
    >>fields??
    >>
    >>> If you want to develop good, structured, and logically/physically tiered
    >>> programs, I strongly recommend adopting Unbound programming practices.

    >>Some
    >>> of the shortcomings of the Bound approach include:
    >>>
    >>> - Bad for n-tier development where your GUI is supposed to be independent
    >>> and oblivious to the database structure. Bound forms link your GUI

    >>directly
    >>> to the data, and make your GUI dependent on the table/view/query layout.

    >>
    >>If you use Datasource classes in a seperate data dll gui is independent.

    >We
    >>use the tag in the control to help with the db mapping. This tag is added
    >>dynamicly. Encapsulation is saved.
    >>
    >>> - Does not support post-entry validation. Lets say for example that you

    >>have
    >>> a text field that needs to be populated and cannot accept an empty string.

    >>
    >>Simply not true, useing a data source class and a recordset dimed withevents
    >>you have complete control over validation. as well as formatting befor
    >>saves.
    >>
    >>> In the GUI with Bound controls it will force the user to enter a value

    >in
    >>> that text entry box before letting them leave the control.

    >>
    >>Not true. Datasource class
    >>
    >>> This can often
    >>> be irritating to the user if they want to defer entering a value in order
    >>> to check, or change another value first. Their only option is to enter

    >an
    >>> potentially invalid value just to move to another selection which can

    >lead
    >>> to data entry errors.
    >>> Post-entry validation would allow the user to enter
    >>> in the values in any order without restrictions, then validate all values
    >>> at once before they perform an action such as saving.

    >>
    >>Datasource class
    >>
    >>> - Keeps a Recordset cursor open for the duration of the form's life.

    >>
    >>No true, Datasource class with disconnected recordset.
    >>
    >>>With
    >>> Bound controls a recordset is left open while the form is loaded. This

    >can
    >>> cause issues with record locking, as well as leave some databases

    >>vulnerable
    >>> to corruption in the event that your application crashes or you use the

    >>Stop
    >>> button from within the VB development environment while the form is

    >>loaded.
    >>
    >>> Using unbound recordsets you can open the recordset, populate your

    >>objects,
    >>> and close the recordset then use the objects to populate your forms

    >>safely.
    >>
    >>Creating a data object for each table causes maintenance problems. (Simply
    >>my view)
    >>
    >>> This leaves the records "free" for other users, however this means you

    >>will
    >>> need to code for change collision detection. (Where if you make changes

    >to
    >>> your objects, you need to check to see if the database has been altered

    >>since
    >>> the time that the data was retrieved and make accommodation for this.)

    >>
    >>We use usercontrols that are bound to datasource classes using the
    >>(Bindingcollection) that give all the benifits of validation,
    >>locking,control over saves deletes, updates. Useing a disconnected recordset
    >>will unlock the db and release the connection cursor. Using withevnts will
    >>allow complete control and give the developer the benifit of a recordset.
    >>Very little coding. We keep these classes in a seperate dll, this gives

    >us
    >>tier support and scalability. Recordlocking is controled by the recordset
    >>automaticly (no extra codeing is required except to trap the error).
    >>Populating an object for each entity (as you suggest) in the db is process
    >>consuming.
    >>
    >>Very easy code resuse as we have over 30+ controls and still counting and
    >>use 2 data source classes. One for list views and one for modifiable views.
    >>Allowing filters,sorts,virtual loading etc. In the same dll we have a gen
    >>sql class that creates a sql statement for the data source classes to
    >>consume. We also have a Command Execute class for all other needs.
    >>We have a db catalog object that is loaded at runtime to give info on any
    >>table of field. Avoiding round trips to the server.
    >>I could go on and on...
    >>
    >>Just my thoughts...
    >>
    >>>
    >>> Steve.
    >>>
    >>> "saly" <iamsmahd@yahoo.com> wrote:
    >>> >
    >>> >Hi every body
    >>> >what is the differences between BOND CONTROLS & UNBOND CONTROLS?
    >>> >
    >>> >thank you very much
    >>>

    >>
    >>

    >



  8. #8
    Jason hawryluk Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS


    "ralph" <nt_consulting32@hotmail.com> a écrit dans le message news:
    3e37db3b$1@tnews.web.devx.com...
    >

    <snip>

    > Very good Jason.
    >
    > I was itching to add my "two cents" but chickened out.
    >
    > Unfortunately I discovered "Data Aware" classes and "ADO Events" too late
    > (about a year ago and now it is time to move on to .NET <g>).


    We are not yet thinking .Net i have been reading the news groups and there
    seems to be a large transition involved that we are not willing to tak at
    this time. All code should port except maybe the data provider layer.

    > But this last year has been great. The combination of UserControls,

    "DataSource"
    > attributes, and Events has led to amazingly simple code (write once and

    forget),
    > seemlessly tiered, and for very robust data handling.


    > When I think back to all that mindless repetitive stuff I wrote for

    years...

    Join the pary...

    Jason



  9. #9
    Jason hawryluk Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS

    oops I ment join the party )


    "Jason hawryluk" <jh@3gcomm.fr> a écrit dans le message news:
    3e3a25a1@tnews.web.devx.com...
    >
    > "ralph" <nt_consulting32@hotmail.com> a écrit dans le message news:
    > 3e37db3b$1@tnews.web.devx.com...
    > >

    > <snip>
    >
    > > Very good Jason.
    > >
    > > I was itching to add my "two cents" but chickened out.
    > >
    > > Unfortunately I discovered "Data Aware" classes and "ADO Events" too

    late
    > > (about a year ago and now it is time to move on to .NET <g>).

    >
    > We are not yet thinking .Net i have been reading the news groups and there
    > seems to be a large transition involved that we are not willing to tak at
    > this time. All code should port except maybe the data provider layer.
    >
    > > But this last year has been great. The combination of UserControls,

    > "DataSource"
    > > attributes, and Events has led to amazingly simple code (write once and

    > forget),
    > > seemlessly tiered, and for very robust data handling.

    >
    > > When I think back to all that mindless repetitive stuff I wrote for

    > years...
    >
    > Join the pary...
    >
    > Jason
    >
    >




  10. #10
    Jason hawryluk Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS

    Comments inline...

    "Steve P." <stevepyn@hotmail.com> a écrit dans le message news:
    3e3877ec$1@tnews.web.devx.com...
    >
    > There are simple, elegant solutions to developing well structured code

    with
    > any tool available if you do the research on how to use the tool

    correctly.
    > (Even with more tempermental topics like GoTo My initial response may

    have
    > sounded a bit harsh like "there is no way you can write well structured

    code
    > with data bound controls." which of course is not true.
    >
    > However,
    >
    > 9 out of 10, or maybe 95 out of 100 people that ask about bound controls
    > are bound(what a pun to be thinking of linking form controls to data

    controls
    > on the GUI.
    >
    > Now I won't have any eggs to throw in people's faces unless they'd care to
    > argue that using data "controls" linked directly to the DB on forms with
    > bound entry controls is a "good" idea... :]



    I agree this is a bad idea, but though I do not use it I imagine it has it's
    place. For example a simple 2 screen app. Or a quick and dirty prototype.

    >
    > The disconnected recordset idea with a Data class was an interesting

    comment.
    > But I am interested to hear how to support post-edit validation. (I.e.

    Don't
    > do any validation until the user hits "Save")I understand that you can

    intercept
    > the event from the RS before the field changes, however if the field in

    the
    > RS is marked Not Null and the user starts entering a value then backs out
    > of the control, how do you avoid the situation that the RS is going to

    complain
    > about an empty value? (I supose ignoring the error would work...) Can the
    > bound control release focus with an invalid value in the control?


    Yes, we do validation on the update, As far as validation goes we do not
    trap the recordset events. We have a update sub that calls validation
    function if false message user telling exactly what problems there are. We
    have a home built data dictionary that this dll uses to do it's work, we
    query this data dictionary to test validation.

    As far as events go we trap (WillChangeRecord) and do select case on the
    adreason, (MoveComplete) for Eof,Bof, and bookmarking
    control,(FetchComplete) as we load async, and (RecordsetChangeComplete) for
    other stuff.

    >
    > The only issue I've run across while using disconnected recordsets (not

    bound,
    > but wrapped) was trying to manage the reconnect and update. (Batch

    Updates)
    > Many of the projects I currently work on I don't have the luxury of

    defining
    > the schema I'm talking to, and the presentation of data is typically

    merged
    > from a number of data tables. This results in quite a few joins, somthing
    > that the disconnected recordsets never seem to want to update. :\ Well

    that
    > and the MS Provider for Oracle not storing row IDs in the cursors, but if
    > I recall right, the joins caused issues with batch updates using the

    Oracle
    > provider.


    For joins are you useing the rs extended property.

    rs_recordset.Properties("Unique Table") = str_DBObjet '**(not using this can
    turn your hair grey in one week flat)

    If not read up on it and the other extended properties as well very handy
    stuff to know.

    We have tables with many joins never had a problem...At this time we use sql
    server have not tried this on oracle.Even though the syntax is different for
    joins, we have one class that generats all sql for the provider this should
    be a easy transition and would not affect any other part of the system. I
    imagine we will create an oracle version of that dll very soon. Converting
    the stored procs are always a pain

    Have you tried the oracle oledb provider. If you are not useing clobs or any
    other oracle specific stuff even the ms oledb provider should work..

    Never had trouble with row ids and the ms or oracle oledb provider. humm
    anyway.

    nice chating..

    Jason

    > Steve.
    >
    > "Jason hawryluk" <jh@3gcomm.fr> wrote:
    > >I am soory all but i do not agree. Comments inline..
    > >
    > >"Steve P" <stevepyn@hotmail.com> a 飲it dans le message news:
    > >3e356cc9$1@tnews.web.devx.com...
    > >>
    > >> Bound controls cover instances where you place a DataControl on a form,

    > >then
    > >> link controls (text boxes, etc.) to that Data Control using the

    DataSource
    > >> property.

    > >
    > >You could also use a data source class. Bound in my mind means a

    control(s)
    > >that are bound to any datasource whether it be a datacontrol, datasource
    > >class or any other data object. Perhaps the binding mechinisime is not

    the
    > >same.
    > >
    > >>
    > >> Unbound controls are where you transfer data to and from the GUI

    > >programatically,
    > >> usually using code-based recordset objects and self-defined entity

    > >classes.
    > >
    > >(self-defined entity classes) Maintenance work change a struc in the db

    > and
    > >change the classes and re deploy. Also limited what about user defined
    > >fields??
    > >
    > >> If you want to develop good, structured, and logically/physically

    tiered
    > >> programs, I strongly recommend adopting Unbound programming practices.

    > >Some
    > >> of the shortcomings of the Bound approach include:
    > >>
    > >> - Bad for n-tier development where your GUI is supposed to be

    independent
    > >> and oblivious to the database structure. Bound forms link your GUI

    > >directly
    > >> to the data, and make your GUI dependent on the table/view/query

    layout.
    > >
    > >If you use Datasource classes in a seperate data dll gui is independent.

    > We
    > >use the tag in the control to help with the db mapping. This tag is added
    > >dynamicly. Encapsulation is saved.
    > >
    > >> - Does not support post-entry validation. Lets say for example that you

    > >have
    > >> a text field that needs to be populated and cannot accept an empty

    string.
    > >
    > >Simply not true, useing a data source class and a recordset dimed

    withevents
    > >you have complete control over validation. as well as formatting befor
    > >saves.
    > >
    > >> In the GUI with Bound controls it will force the user to enter a value

    > in
    > >> that text entry box before letting them leave the control.

    > >
    > >Not true. Datasource class
    > >
    > >> This can often
    > >> be irritating to the user if they want to defer entering a value in

    order
    > >> to check, or change another value first. Their only option is to enter

    > an
    > >> potentially invalid value just to move to another selection which can

    > lead
    > >> to data entry errors.
    > >> Post-entry validation would allow the user to enter
    > >> in the values in any order without restrictions, then validate all

    values
    > >> at once before they perform an action such as saving.

    > >
    > >Datasource class
    > >
    > >> - Keeps a Recordset cursor open for the duration of the form's life.

    > >
    > >No true, Datasource class with disconnected recordset.
    > >
    > >>With
    > >> Bound controls a recordset is left open while the form is loaded. This

    > can
    > >> cause issues with record locking, as well as leave some databases

    > >vulnerable
    > >> to corruption in the event that your application crashes or you use the

    > >Stop
    > >> button from within the VB development environment while the form is

    > >loaded.
    > >
    > >> Using unbound recordsets you can open the recordset, populate your

    > >objects,
    > >> and close the recordset then use the objects to populate your forms

    > >safely.
    > >
    > >Creating a data object for each table causes maintenance problems.

    (Simply
    > >my view)
    > >
    > >> This leaves the records "free" for other users, however this means you

    > >will
    > >> need to code for change collision detection. (Where if you make changes

    > to
    > >> your objects, you need to check to see if the database has been altered

    > >since
    > >> the time that the data was retrieved and make accommodation for this.)

    > >
    > >We use usercontrols that are bound to datasource classes using the
    > >(Bindingcollection) that give all the benifits of validation,
    > >locking,control over saves deletes, updates. Useing a disconnected

    recordset
    > >will unlock the db and release the connection cursor. Using withevnts

    will
    > >allow complete control and give the developer the benifit of a recordset.
    > >Very little coding. We keep these classes in a seperate dll, this gives

    > us
    > >tier support and scalability. Recordlocking is controled by the recordset
    > >automaticly (no extra codeing is required except to trap the error).
    > >Populating an object for each entity (as you suggest) in the db is

    process
    > >consuming.
    > >
    > >Very easy code resuse as we have over 30+ controls and still counting and
    > >use 2 data source classes. One for list views and one for modifiable

    views.
    > >Allowing filters,sorts,virtual loading etc. In the same dll we have a gen
    > >sql class that creates a sql statement for the data source classes to
    > >consume. We also have a Command Execute class for all other needs.
    > >We have a db catalog object that is loaded at runtime to give info on any
    > >table of field. Avoiding round trips to the server.
    > >I could go on and on...
    > >
    > >Just my thoughts...
    > >
    > >>
    > >> Steve.
    > >>
    > >> "saly" <iamsmahd@yahoo.com> wrote:
    > >> >
    > >> >Hi every body
    > >> >what is the differences between BOND CONTROLS & UNBOND CONTROLS?
    > >> >
    > >> >thank you very much
    > >>

    > >
    > >

    >




  11. #11
    Chris Hylton Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS


    To add to Jason's comments...you might also want to include the rowid in the
    select statement along w/ a to_char conversion (i seem to recall you can't
    just plain old 'to_char' a rowid, but you can convert it to string)...but,
    the point is, if you are finding that even w/ rowid in your select that the
    rowid doesn't come through into the recordset, it's something about the data
    provider, but you can get around it by converting the rowid...then you have
    it for update statements and command objects...

    Second, Jason...can you expound on the extended properties issue...I've found
    instance where I do a 'select 0 as my_update_flag' in something like Access
    or SQL Server and then the recordset won't let me update this value...is
    there a way to get around it ?

    In Oracle, the way I've gotten around this is to wrapper my actual select
    in a 'select * from (mysqlstatement)' and this allows me to update any field...but
    if there is an extended property I can use w/ a disconnected recordset to
    get around this, it would be pretty handy for the toolbox...

    Too bad most of the extended properties from MS are not well documented...

    Chris

    "Jason hawryluk" <jh@3gcomm.fr> wrote:
    >Comments inline...
    >
    >"Steve P." <stevepyn@hotmail.com> a écrit dans le message news:
    >3e3877ec$1@tnews.web.devx.com...
    >>
    >> There are simple, elegant solutions to developing well structured code

    >with
    >> any tool available if you do the research on how to use the tool

    >correctly.
    >> (Even with more tempermental topics like GoTo My initial response may

    >have
    >> sounded a bit harsh like "there is no way you can write well structured

    >code
    >> with data bound controls." which of course is not true.
    >>
    >> However,
    >>
    >> 9 out of 10, or maybe 95 out of 100 people that ask about bound controls
    >> are bound(what a pun to be thinking of linking form controls to data

    >controls
    >> on the GUI.
    >>
    >> Now I won't have any eggs to throw in people's faces unless they'd care

    to
    >> argue that using data "controls" linked directly to the DB on forms with
    >> bound entry controls is a "good" idea... :]

    >
    >
    >I agree this is a bad idea, but though I do not use it I imagine it has

    it's
    >place. For example a simple 2 screen app. Or a quick and dirty prototype.
    >
    >>
    >> The disconnected recordset idea with a Data class was an interesting

    >comment.
    >> But I am interested to hear how to support post-edit validation. (I.e.

    >Don't
    >> do any validation until the user hits "Save")I understand that you can

    >intercept
    >> the event from the RS before the field changes, however if the field in

    >the
    >> RS is marked Not Null and the user starts entering a value then backs

    out
    >> of the control, how do you avoid the situation that the RS is going to

    >complain
    >> about an empty value? (I supose ignoring the error would work...) Can

    the
    >> bound control release focus with an invalid value in the control?

    >
    >Yes, we do validation on the update, As far as validation goes we do not
    >trap the recordset events. We have a update sub that calls validation
    >function if false message user telling exactly what problems there are.

    We
    >have a home built data dictionary that this dll uses to do it's work, we
    >query this data dictionary to test validation.
    >
    >As far as events go we trap (WillChangeRecord) and do select case on the
    >adreason, (MoveComplete) for Eof,Bof, and bookmarking
    >control,(FetchComplete) as we load async, and (RecordsetChangeComplete)

    for
    >other stuff.
    >
    >>
    >> The only issue I've run across while using disconnected recordsets (not

    >bound,
    >> but wrapped) was trying to manage the reconnect and update. (Batch

    >Updates)
    >> Many of the projects I currently work on I don't have the luxury of

    >defining
    >> the schema I'm talking to, and the presentation of data is typically

    >merged
    >> from a number of data tables. This results in quite a few joins, somthing
    >> that the disconnected recordsets never seem to want to update. :\ Well

    >that
    >> and the MS Provider for Oracle not storing row IDs in the cursors, but

    if
    >> I recall right, the joins caused issues with batch updates using the

    >Oracle
    >> provider.

    >
    >For joins are you useing the rs extended property.
    >
    >rs_recordset.Properties("Unique Table") = str_DBObjet '**(not using this

    can
    >turn your hair grey in one week flat)
    >
    >If not read up on it and the other extended properties as well very handy
    >stuff to know.
    >
    >We have tables with many joins never had a problem...At this time we use

    sql
    >server have not tried this on oracle.Even though the syntax is different

    for
    >joins, we have one class that generats all sql for the provider this should
    >be a easy transition and would not affect any other part of the system.

    I
    >imagine we will create an oracle version of that dll very soon. Converting
    >the stored procs are always a pain
    >
    >Have you tried the oracle oledb provider. If you are not useing clobs or

    any
    >other oracle specific stuff even the ms oledb provider should work..
    >
    >Never had trouble with row ids and the ms or oracle oledb provider. humm
    >anyway.
    >
    >nice chating..
    >
    >Jason
    >
    >> Steve.
    >>
    >> "Jason hawryluk" <jh@3gcomm.fr> wrote:
    >> >I am soory all but i do not agree. Comments inline..
    >> >
    >> >"Steve P" <stevepyn@hotmail.com> a 飲it dans le message news:
    >> >3e356cc9$1@tnews.web.devx.com...
    >> >>
    >> >> Bound controls cover instances where you place a DataControl on a form,
    >> >then
    >> >> link controls (text boxes, etc.) to that Data Control using the

    >DataSource
    >> >> property.
    >> >
    >> >You could also use a data source class. Bound in my mind means a

    >control(s)
    >> >that are bound to any datasource whether it be a datacontrol, datasource
    >> >class or any other data object. Perhaps the binding mechinisime is not

    >the
    >> >same.
    >> >
    >> >>
    >> >> Unbound controls are where you transfer data to and from the GUI
    >> >programatically,
    >> >> usually using code-based recordset objects and self-defined entity
    >> >classes.
    >> >
    >> >(self-defined entity classes) Maintenance work change a struc in the

    db
    >> and
    >> >change the classes and re deploy. Also limited what about user defined
    >> >fields??
    >> >
    >> >> If you want to develop good, structured, and logically/physically

    >tiered
    >> >> programs, I strongly recommend adopting Unbound programming practices.
    >> >Some
    >> >> of the shortcomings of the Bound approach include:
    >> >>
    >> >> - Bad for n-tier development where your GUI is supposed to be

    >independent
    >> >> and oblivious to the database structure. Bound forms link your GUI
    >> >directly
    >> >> to the data, and make your GUI dependent on the table/view/query

    >layout.
    >> >
    >> >If you use Datasource classes in a seperate data dll gui is independent.

    >> We
    >> >use the tag in the control to help with the db mapping. This tag is added
    >> >dynamicly. Encapsulation is saved.
    >> >
    >> >> - Does not support post-entry validation. Lets say for example that

    you
    >> >have
    >> >> a text field that needs to be populated and cannot accept an empty

    >string.
    >> >
    >> >Simply not true, useing a data source class and a recordset dimed

    >withevents
    >> >you have complete control over validation. as well as formatting befor
    >> >saves.
    >> >
    >> >> In the GUI with Bound controls it will force the user to enter a value

    >> in
    >> >> that text entry box before letting them leave the control.
    >> >
    >> >Not true. Datasource class
    >> >
    >> >> This can often
    >> >> be irritating to the user if they want to defer entering a value in

    >order
    >> >> to check, or change another value first. Their only option is to enter

    >> an
    >> >> potentially invalid value just to move to another selection which can

    >> lead
    >> >> to data entry errors.
    >> >> Post-entry validation would allow the user to enter
    >> >> in the values in any order without restrictions, then validate all

    >values
    >> >> at once before they perform an action such as saving.
    >> >
    >> >Datasource class
    >> >
    >> >> - Keeps a Recordset cursor open for the duration of the form's life.
    >> >
    >> >No true, Datasource class with disconnected recordset.
    >> >
    >> >>With
    >> >> Bound controls a recordset is left open while the form is loaded. This

    >> can
    >> >> cause issues with record locking, as well as leave some databases
    >> >vulnerable
    >> >> to corruption in the event that your application crashes or you use

    the
    >> >Stop
    >> >> button from within the VB development environment while the form is
    >> >loaded.
    >> >
    >> >> Using unbound recordsets you can open the recordset, populate your
    >> >objects,
    >> >> and close the recordset then use the objects to populate your forms
    >> >safely.
    >> >
    >> >Creating a data object for each table causes maintenance problems.

    >(Simply
    >> >my view)
    >> >
    >> >> This leaves the records "free" for other users, however this means

    you
    >> >will
    >> >> need to code for change collision detection. (Where if you make changes

    >> to
    >> >> your objects, you need to check to see if the database has been altered
    >> >since
    >> >> the time that the data was retrieved and make accommodation for this.)
    >> >
    >> >We use usercontrols that are bound to datasource classes using the
    >> >(Bindingcollection) that give all the benifits of validation,
    >> >locking,control over saves deletes, updates. Useing a disconnected

    >recordset
    >> >will unlock the db and release the connection cursor. Using withevnts

    >will
    >> >allow complete control and give the developer the benifit of a recordset.
    >> >Very little coding. We keep these classes in a seperate dll, this gives

    >> us
    >> >tier support and scalability. Recordlocking is controled by the recordset
    >> >automaticly (no extra codeing is required except to trap the error).
    >> >Populating an object for each entity (as you suggest) in the db is

    >process
    >> >consuming.
    >> >
    >> >Very easy code resuse as we have over 30+ controls and still counting

    and
    >> >use 2 data source classes. One for list views and one for modifiable

    >views.
    >> >Allowing filters,sorts,virtual loading etc. In the same dll we have a

    gen
    >> >sql class that creates a sql statement for the data source classes to
    >> >consume. We also have a Command Execute class for all other needs.
    >> >We have a db catalog object that is loaded at runtime to give info on

    any
    >> >table of field. Avoiding round trips to the server.
    >> >I could go on and on...
    >> >
    >> >Just my thoughts...
    >> >
    >> >>
    >> >> Steve.
    >> >>
    >> >> "saly" <iamsmahd@yahoo.com> wrote:
    >> >> >
    >> >> >Hi every body
    >> >> >what is the differences between BOND CONTROLS & UNBOND CONTROLS?
    >> >> >
    >> >> >thank you very much
    >> >>
    >> >
    >> >

    >>

    >
    >



  12. #12
    Jason hawryluk Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS

    in line

    "Chris Hylton" <cchylton@hotmail.com> a écrit dans le message news:
    3e3b0fc1$1@tnews.web.devx.com...
    >
    > To add to Jason's comments...you might also want to include the rowid in

    the
    > select statement along w/ a to_char conversion (i seem to recall you can't
    > just plain old 'to_char' a rowid, but you can convert it to string)...but,
    > the point is, if you are finding that even w/ rowid in your select that

    the
    > rowid doesn't come through into the recordset, it's something about the

    data
    > provider, but you can get around it by converting the rowid...then you

    have
    > it for update statements and command objects...
    >
    > Second, Jason...can you expound on the extended properties issue...I've

    found
    > instance where I do a 'select 0 as my_update_flag' in something like

    Access
    > or SQL Server and then the recordset won't let me update this value...is
    > there a way to get around it ?


    The particular property that i mentioned is for updateing the main table on
    a recordset with joins. Where as the table specified in the property setting
    is the only table updated,or re synced etc... Sorry i could not give a
    educated response to your question with out further research. I have never
    tryed the above mentioned 'select 0 as my_update_flag' with this property
    set.

    >
    > In Oracle, the way I've gotten around this is to wrapper my actual select
    > in a 'select * from (mysqlstatement)' and this allows me to update any

    field...but
    > if there is an extended property I can use w/ a disconnected recordset to
    > get around this, it would be pretty handy for the toolbox...
    >
    > Too bad most of the extended properties from MS are not well documented...


    I agree the documentaion is limited. I am sure that there is tons of stuff
    we can do but never knew we could...(if that maks sence at all Sorry i am
    not very Oracle savy, only ever built one large web app that uses it (man i
    hate clobs, had to store binary encrypted results from an electronic
    signature). I have to confess we are a mostly MS shop.

    cheers..

    Jason

    > Chris
    >
    > "Jason hawryluk" <jh@3gcomm.fr> wrote:
    > >Comments inline...
    > >
    > >"Steve P." <stevepyn@hotmail.com> a écrit dans le message news:
    > >3e3877ec$1@tnews.web.devx.com...
    > >>
    > >> There are simple, elegant solutions to developing well structured code

    > >with
    > >> any tool available if you do the research on how to use the tool

    > >correctly.
    > >> (Even with more tempermental topics like GoTo My initial response may

    > >have
    > >> sounded a bit harsh like "there is no way you can write well structured

    > >code
    > >> with data bound controls." which of course is not true.
    > >>
    > >> However,
    > >>
    > >> 9 out of 10, or maybe 95 out of 100 people that ask about bound

    controls
    > >> are bound(what a pun to be thinking of linking form controls to data

    > >controls
    > >> on the GUI.
    > >>
    > >> Now I won't have any eggs to throw in people's faces unless they'd care

    > to
    > >> argue that using data "controls" linked directly to the DB on forms

    with
    > >> bound entry controls is a "good" idea... :]

    > >
    > >
    > >I agree this is a bad idea, but though I do not use it I imagine it has

    > it's
    > >place. For example a simple 2 screen app. Or a quick and dirty prototype.
    > >
    > >>
    > >> The disconnected recordset idea with a Data class was an interesting

    > >comment.
    > >> But I am interested to hear how to support post-edit validation. (I.e.

    > >Don't
    > >> do any validation until the user hits "Save")I understand that you can

    > >intercept
    > >> the event from the RS before the field changes, however if the field in

    > >the
    > >> RS is marked Not Null and the user starts entering a value then backs

    > out
    > >> of the control, how do you avoid the situation that the RS is going to

    > >complain
    > >> about an empty value? (I supose ignoring the error would work...) Can

    > the
    > >> bound control release focus with an invalid value in the control?

    > >
    > >Yes, we do validation on the update, As far as validation goes we do not
    > >trap the recordset events. We have a update sub that calls validation
    > >function if false message user telling exactly what problems there are.

    > We
    > >have a home built data dictionary that this dll uses to do it's work, we
    > >query this data dictionary to test validation.
    > >
    > >As far as events go we trap (WillChangeRecord) and do select case on the
    > >adreason, (MoveComplete) for Eof,Bof, and bookmarking
    > >control,(FetchComplete) as we load async, and (RecordsetChangeComplete)

    > for
    > >other stuff.
    > >
    > >>
    > >> The only issue I've run across while using disconnected recordsets (not

    > >bound,
    > >> but wrapped) was trying to manage the reconnect and update. (Batch

    > >Updates)
    > >> Many of the projects I currently work on I don't have the luxury of

    > >defining
    > >> the schema I'm talking to, and the presentation of data is typically

    > >merged
    > >> from a number of data tables. This results in quite a few joins,

    somthing
    > >> that the disconnected recordsets never seem to want to update. :\ Well

    > >that
    > >> and the MS Provider for Oracle not storing row IDs in the cursors, but

    > if
    > >> I recall right, the joins caused issues with batch updates using the

    > >Oracle
    > >> provider.

    > >
    > >For joins are you useing the rs extended property.
    > >
    > >rs_recordset.Properties("Unique Table") = str_DBObjet '**(not using this

    > can
    > >turn your hair grey in one week flat)
    > >
    > >If not read up on it and the other extended properties as well very handy
    > >stuff to know.
    > >
    > >We have tables with many joins never had a problem...At this time we use

    > sql
    > >server have not tried this on oracle.Even though the syntax is different

    > for
    > >joins, we have one class that generats all sql for the provider this

    should
    > >be a easy transition and would not affect any other part of the system.

    > I
    > >imagine we will create an oracle version of that dll very soon.

    Converting
    > >the stored procs are always a pain
    > >
    > >Have you tried the oracle oledb provider. If you are not useing clobs or

    > any
    > >other oracle specific stuff even the ms oledb provider should work..
    > >
    > >Never had trouble with row ids and the ms or oracle oledb provider. humm
    > >anyway.
    > >
    > >nice chating..
    > >
    > >Jason
    > >
    > >> Steve.
    > >>
    > >> "Jason hawryluk" <jh@3gcomm.fr> wrote:
    > >> >I am soory all but i do not agree. Comments inline..
    > >> >
    > >> >"Steve P" <stevepyn@hotmail.com> a 飲it dans le message news:
    > >> >3e356cc9$1@tnews.web.devx.com...
    > >> >>
    > >> >> Bound controls cover instances where you place a DataControl on a

    form,
    > >> >then
    > >> >> link controls (text boxes, etc.) to that Data Control using the

    > >DataSource
    > >> >> property.
    > >> >
    > >> >You could also use a data source class. Bound in my mind means a

    > >control(s)
    > >> >that are bound to any datasource whether it be a datacontrol,

    datasource
    > >> >class or any other data object. Perhaps the binding mechinisime is not

    > >the
    > >> >same.
    > >> >
    > >> >>
    > >> >> Unbound controls are where you transfer data to and from the GUI
    > >> >programatically,
    > >> >> usually using code-based recordset objects and self-defined entity
    > >> >classes.
    > >> >
    > >> >(self-defined entity classes) Maintenance work change a struc in the

    > db
    > >> and
    > >> >change the classes and re deploy. Also limited what about user defined
    > >> >fields??
    > >> >
    > >> >> If you want to develop good, structured, and logically/physically

    > >tiered
    > >> >> programs, I strongly recommend adopting Unbound programming

    practices.
    > >> >Some
    > >> >> of the shortcomings of the Bound approach include:
    > >> >>
    > >> >> - Bad for n-tier development where your GUI is supposed to be

    > >independent
    > >> >> and oblivious to the database structure. Bound forms link your GUI
    > >> >directly
    > >> >> to the data, and make your GUI dependent on the table/view/query

    > >layout.
    > >> >
    > >> >If you use Datasource classes in a seperate data dll gui is

    independent.
    > >> We
    > >> >use the tag in the control to help with the db mapping. This tag is

    added
    > >> >dynamicly. Encapsulation is saved.
    > >> >
    > >> >> - Does not support post-entry validation. Lets say for example that

    > you
    > >> >have
    > >> >> a text field that needs to be populated and cannot accept an empty

    > >string.
    > >> >
    > >> >Simply not true, useing a data source class and a recordset dimed

    > >withevents
    > >> >you have complete control over validation. as well as formatting befor
    > >> >saves.
    > >> >
    > >> >> In the GUI with Bound controls it will force the user to enter a

    value
    > >> in
    > >> >> that text entry box before letting them leave the control.
    > >> >
    > >> >Not true. Datasource class
    > >> >
    > >> >> This can often
    > >> >> be irritating to the user if they want to defer entering a value in

    > >order
    > >> >> to check, or change another value first. Their only option is to

    enter
    > >> an
    > >> >> potentially invalid value just to move to another selection which

    can
    > >> lead
    > >> >> to data entry errors.
    > >> >> Post-entry validation would allow the user to enter
    > >> >> in the values in any order without restrictions, then validate all

    > >values
    > >> >> at once before they perform an action such as saving.
    > >> >
    > >> >Datasource class
    > >> >
    > >> >> - Keeps a Recordset cursor open for the duration of the form's life.
    > >> >
    > >> >No true, Datasource class with disconnected recordset.
    > >> >
    > >> >>With
    > >> >> Bound controls a recordset is left open while the form is loaded.

    This
    > >> can
    > >> >> cause issues with record locking, as well as leave some databases
    > >> >vulnerable
    > >> >> to corruption in the event that your application crashes or you use

    > the
    > >> >Stop
    > >> >> button from within the VB development environment while the form is
    > >> >loaded.
    > >> >
    > >> >> Using unbound recordsets you can open the recordset, populate your
    > >> >objects,
    > >> >> and close the recordset then use the objects to populate your forms
    > >> >safely.
    > >> >
    > >> >Creating a data object for each table causes maintenance problems.

    > >(Simply
    > >> >my view)
    > >> >
    > >> >> This leaves the records "free" for other users, however this means

    > you
    > >> >will
    > >> >> need to code for change collision detection. (Where if you make

    changes
    > >> to
    > >> >> your objects, you need to check to see if the database has been

    altered
    > >> >since
    > >> >> the time that the data was retrieved and make accommodation for

    this.)
    > >> >
    > >> >We use usercontrols that are bound to datasource classes using the
    > >> >(Bindingcollection) that give all the benifits of validation,
    > >> >locking,control over saves deletes, updates. Useing a disconnected

    > >recordset
    > >> >will unlock the db and release the connection cursor. Using withevnts

    > >will
    > >> >allow complete control and give the developer the benifit of a

    recordset.
    > >> >Very little coding. We keep these classes in a seperate dll, this

    gives
    > >> us
    > >> >tier support and scalability. Recordlocking is controled by the

    recordset
    > >> >automaticly (no extra codeing is required except to trap the error).
    > >> >Populating an object for each entity (as you suggest) in the db is

    > >process
    > >> >consuming.
    > >> >
    > >> >Very easy code resuse as we have over 30+ controls and still counting

    > and
    > >> >use 2 data source classes. One for list views and one for modifiable

    > >views.
    > >> >Allowing filters,sorts,virtual loading etc. In the same dll we have a

    > gen
    > >> >sql class that creates a sql statement for the data source classes to
    > >> >consume. We also have a Command Execute class for all other needs.
    > >> >We have a db catalog object that is loaded at runtime to give info on

    > any
    > >> >table of field. Avoiding round trips to the server.
    > >> >I could go on and on...
    > >> >
    > >> >Just my thoughts...
    > >> >
    > >> >>
    > >> >> Steve.
    > >> >>
    > >> >> "saly" <iamsmahd@yahoo.com> wrote:
    > >> >> >
    > >> >> >Hi every body
    > >> >> >what is the differences between BOND CONTROLS & UNBOND CONTROLS?
    > >> >> >
    > >> >> >thank you very much
    > >> >>
    > >> >
    > >> >
    > >>

    > >
    > >

    >




  13. #13
    Chris Hylton Guest

    Re: BOND CONTROLS vs. UNBOND CONTROLS


    Nope, that was the exact answer I was looking for...on the extended property...thanks...

    I was thinking maybe there was an extended property that would allow the
    'O as updated_flag' deal to actually update the local disconnected recordset
    when it's not usually allowed (b/c it's not part of an actual underlying
    table)...but, sounds like that's not the case based on your explanation.

    I use that technique (0 as updated) to have a flag on the row when a local
    disconnected recordset row is updated somewhere in the fields...that way
    when I get ready to post back, I know which records to send...I pretty much
    try to never allow updates directly through the recordset, everything goes
    back thru a stored proc or in very few instances an update statement fired
    thru a .Execute on the connection.

    I'm not a big Oracle guy either...just using it alot these days w/ certain
    clients...I'm a dedicated MS guy whenever possible...not much of a fan of
    Oracle...

    Chris

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