BOND CONTROLS vs. UNBOND CONTROLS

[saly]

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

thank you very much

[Arthur Wood]

"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

[Steve P]

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

[Jason hawryluk]

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
>

[ralph]

"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

[Steve P.]

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
>>
>
>

[Chris Hylton]

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
>>>
>>
>>
>

[Jason hawryluk]

"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

[Jason hawryluk]

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
>
>

[Jason hawryluk]

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
> >>
> >
> >
>

[Chris Hylton]

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
>> >>
>> >
>> >
>>
>
>

[Jason hawryluk]

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
> >> >>
> >> >
> >> >
> >>
> >
> >
>

[Chris Hylton]

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