Is it safe to share a TDataSource between several controls at the same time?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I have moved all my lookup tables/queries in the main DataModule of my application. Now I wonder if I could also move the associated TDataSource
to the Datamodule.
For example, if I have two TLookupCombobox
on two different forms (or even on the same form) using the same TDataSource
, will this have an impact ? Like when I choose an item in combobox1 will it move to the same item on combobox2 ?
I only want to use these TDataSources
read only.
delphi
add a comment |
I have moved all my lookup tables/queries in the main DataModule of my application. Now I wonder if I could also move the associated TDataSource
to the Datamodule.
For example, if I have two TLookupCombobox
on two different forms (or even on the same form) using the same TDataSource
, will this have an impact ? Like when I choose an item in combobox1 will it move to the same item on combobox2 ?
I only want to use these TDataSources
read only.
delphi
yes, it is safe. but if your application is big, sharing datasources will be a bad thing. it is very hard to maintain in the long run
– Ago
Jan 4 at 8:44
add a comment |
I have moved all my lookup tables/queries in the main DataModule of my application. Now I wonder if I could also move the associated TDataSource
to the Datamodule.
For example, if I have two TLookupCombobox
on two different forms (or even on the same form) using the same TDataSource
, will this have an impact ? Like when I choose an item in combobox1 will it move to the same item on combobox2 ?
I only want to use these TDataSources
read only.
delphi
I have moved all my lookup tables/queries in the main DataModule of my application. Now I wonder if I could also move the associated TDataSource
to the Datamodule.
For example, if I have two TLookupCombobox
on two different forms (or even on the same form) using the same TDataSource
, will this have an impact ? Like when I choose an item in combobox1 will it move to the same item on combobox2 ?
I only want to use these TDataSources
read only.
delphi
delphi
asked Jan 4 at 0:26
JC BoggioJC Boggio
1226
1226
yes, it is safe. but if your application is big, sharing datasources will be a bad thing. it is very hard to maintain in the long run
– Ago
Jan 4 at 8:44
add a comment |
yes, it is safe. but if your application is big, sharing datasources will be a bad thing. it is very hard to maintain in the long run
– Ago
Jan 4 at 8:44
yes, it is safe. but if your application is big, sharing datasources will be a bad thing. it is very hard to maintain in the long run
– Ago
Jan 4 at 8:44
yes, it is safe. but if your application is big, sharing datasources will be a bad thing. it is very hard to maintain in the long run
– Ago
Jan 4 at 8:44
add a comment |
2 Answers
2
active
oldest
votes
Yes, it is possible for a TDataSource to be placed in a TDataModule and used as the datasource for db-aware components on a number of forms. However, it is generally not a good idea and is one you are likely to come to regret. Doing it creates a maintenance problem for yourself, because it is rather too easy to make some change to its properties which affects how the db-aware components behave and overlook the knock-on consequenes for the various forms (same is true for TDataSet descendants, of course).
Sharing a datasource across forms can impact on performance if instances of the forms exist at the same time, and this is particularly so if you carry out some procedure which iterates the records in the dataset (unless you surround the operation with calls to TDataSet.DisableControls and .EnableControls).
So imo although there are benefits to placing datasets in a datamodule which is used by a number of forms, it is far better to place the datasource(s) on the forms which contain the connected db-aware components.
So far as db-aware compound controls such as TDBComboBox, TDBListBox, etc are concerned, these always display the value from the current record in the related dataset. No amount of coding will permit these components to simultneously display different field values on different forms: if they are fed by the same datasource from the same record field, they will display the same value (though of course, the contents of associated lists in the controls, as in the drop-down list of a DBComboBox, may differ between them). This arises from the way TDataSets are designed to operate: they all implement a dataset "cursor" which makes all data-reading and -writing operations operate on a single, "current" record of the dataset and the value of the dataset field which a db-aware component displays is the value in the record the cursor is on.
From what I understand of your last paragraph, the problem is the TDataset itself, not really the TDataSource. I don't want any event connected to these datasets and datasources, they are just sources for LookupComboboxes. And I should have mentionned that I am using DevExpress components in non-SyncMode (the components use an internal cache and selecting a value won't affect the underlying TDataset descendant's cursor). So in this kind of use, it should not induce side-effects/artefacts.
– JC Boggio
Jan 4 at 13:37
I'm not sure what you mean by "the problem": if you mean the fact that all db-aware components connected to the same dataset field will always display the same value, that arises simply because of the way the TDataSet descendants all work, namely they all implement a dataset "cursor" which make all data-reading and -writing operations operate on a single, "current" record of the dataset.
– MartynA
Jan 4 at 15:27
add a comment |
You are asking two questions there. - No problem.
On the usage of the Datasource, absolutely. I have all my TTables, TQuerys and DatSources in the one DataModule aand reference them from multiple Forms with multiple components on each.
On the combobox1 v combobox2 interaction, it will depend on the code behind them. Nominally in the OnChange event.
Ian
MartynA - DBCombobox was not specified, only ComboBox. I prefer not to make assumptions. Had DBCombobox been specified my answer to that part would have been different.
– Ian Branch
Jan 4 at 22:11
Fair enough - I assumed the OP's omission of the TDB prefix was a typo, as he specfically said " if I have two TLookupCombobox ...**using** the same TDataSource" , and they could only use a datasource at all if they were the db-aware type. Anyway, I've edited my answer to avoid saying that I disagree with this onr.
– MartynA
Jan 4 at 22:22
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54031649%2fis-it-safe-to-share-a-tdatasource-between-several-controls-at-the-same-time%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes, it is possible for a TDataSource to be placed in a TDataModule and used as the datasource for db-aware components on a number of forms. However, it is generally not a good idea and is one you are likely to come to regret. Doing it creates a maintenance problem for yourself, because it is rather too easy to make some change to its properties which affects how the db-aware components behave and overlook the knock-on consequenes for the various forms (same is true for TDataSet descendants, of course).
Sharing a datasource across forms can impact on performance if instances of the forms exist at the same time, and this is particularly so if you carry out some procedure which iterates the records in the dataset (unless you surround the operation with calls to TDataSet.DisableControls and .EnableControls).
So imo although there are benefits to placing datasets in a datamodule which is used by a number of forms, it is far better to place the datasource(s) on the forms which contain the connected db-aware components.
So far as db-aware compound controls such as TDBComboBox, TDBListBox, etc are concerned, these always display the value from the current record in the related dataset. No amount of coding will permit these components to simultneously display different field values on different forms: if they are fed by the same datasource from the same record field, they will display the same value (though of course, the contents of associated lists in the controls, as in the drop-down list of a DBComboBox, may differ between them). This arises from the way TDataSets are designed to operate: they all implement a dataset "cursor" which makes all data-reading and -writing operations operate on a single, "current" record of the dataset and the value of the dataset field which a db-aware component displays is the value in the record the cursor is on.
From what I understand of your last paragraph, the problem is the TDataset itself, not really the TDataSource. I don't want any event connected to these datasets and datasources, they are just sources for LookupComboboxes. And I should have mentionned that I am using DevExpress components in non-SyncMode (the components use an internal cache and selecting a value won't affect the underlying TDataset descendant's cursor). So in this kind of use, it should not induce side-effects/artefacts.
– JC Boggio
Jan 4 at 13:37
I'm not sure what you mean by "the problem": if you mean the fact that all db-aware components connected to the same dataset field will always display the same value, that arises simply because of the way the TDataSet descendants all work, namely they all implement a dataset "cursor" which make all data-reading and -writing operations operate on a single, "current" record of the dataset.
– MartynA
Jan 4 at 15:27
add a comment |
Yes, it is possible for a TDataSource to be placed in a TDataModule and used as the datasource for db-aware components on a number of forms. However, it is generally not a good idea and is one you are likely to come to regret. Doing it creates a maintenance problem for yourself, because it is rather too easy to make some change to its properties which affects how the db-aware components behave and overlook the knock-on consequenes for the various forms (same is true for TDataSet descendants, of course).
Sharing a datasource across forms can impact on performance if instances of the forms exist at the same time, and this is particularly so if you carry out some procedure which iterates the records in the dataset (unless you surround the operation with calls to TDataSet.DisableControls and .EnableControls).
So imo although there are benefits to placing datasets in a datamodule which is used by a number of forms, it is far better to place the datasource(s) on the forms which contain the connected db-aware components.
So far as db-aware compound controls such as TDBComboBox, TDBListBox, etc are concerned, these always display the value from the current record in the related dataset. No amount of coding will permit these components to simultneously display different field values on different forms: if they are fed by the same datasource from the same record field, they will display the same value (though of course, the contents of associated lists in the controls, as in the drop-down list of a DBComboBox, may differ between them). This arises from the way TDataSets are designed to operate: they all implement a dataset "cursor" which makes all data-reading and -writing operations operate on a single, "current" record of the dataset and the value of the dataset field which a db-aware component displays is the value in the record the cursor is on.
From what I understand of your last paragraph, the problem is the TDataset itself, not really the TDataSource. I don't want any event connected to these datasets and datasources, they are just sources for LookupComboboxes. And I should have mentionned that I am using DevExpress components in non-SyncMode (the components use an internal cache and selecting a value won't affect the underlying TDataset descendant's cursor). So in this kind of use, it should not induce side-effects/artefacts.
– JC Boggio
Jan 4 at 13:37
I'm not sure what you mean by "the problem": if you mean the fact that all db-aware components connected to the same dataset field will always display the same value, that arises simply because of the way the TDataSet descendants all work, namely they all implement a dataset "cursor" which make all data-reading and -writing operations operate on a single, "current" record of the dataset.
– MartynA
Jan 4 at 15:27
add a comment |
Yes, it is possible for a TDataSource to be placed in a TDataModule and used as the datasource for db-aware components on a number of forms. However, it is generally not a good idea and is one you are likely to come to regret. Doing it creates a maintenance problem for yourself, because it is rather too easy to make some change to its properties which affects how the db-aware components behave and overlook the knock-on consequenes for the various forms (same is true for TDataSet descendants, of course).
Sharing a datasource across forms can impact on performance if instances of the forms exist at the same time, and this is particularly so if you carry out some procedure which iterates the records in the dataset (unless you surround the operation with calls to TDataSet.DisableControls and .EnableControls).
So imo although there are benefits to placing datasets in a datamodule which is used by a number of forms, it is far better to place the datasource(s) on the forms which contain the connected db-aware components.
So far as db-aware compound controls such as TDBComboBox, TDBListBox, etc are concerned, these always display the value from the current record in the related dataset. No amount of coding will permit these components to simultneously display different field values on different forms: if they are fed by the same datasource from the same record field, they will display the same value (though of course, the contents of associated lists in the controls, as in the drop-down list of a DBComboBox, may differ between them). This arises from the way TDataSets are designed to operate: they all implement a dataset "cursor" which makes all data-reading and -writing operations operate on a single, "current" record of the dataset and the value of the dataset field which a db-aware component displays is the value in the record the cursor is on.
Yes, it is possible for a TDataSource to be placed in a TDataModule and used as the datasource for db-aware components on a number of forms. However, it is generally not a good idea and is one you are likely to come to regret. Doing it creates a maintenance problem for yourself, because it is rather too easy to make some change to its properties which affects how the db-aware components behave and overlook the knock-on consequenes for the various forms (same is true for TDataSet descendants, of course).
Sharing a datasource across forms can impact on performance if instances of the forms exist at the same time, and this is particularly so if you carry out some procedure which iterates the records in the dataset (unless you surround the operation with calls to TDataSet.DisableControls and .EnableControls).
So imo although there are benefits to placing datasets in a datamodule which is used by a number of forms, it is far better to place the datasource(s) on the forms which contain the connected db-aware components.
So far as db-aware compound controls such as TDBComboBox, TDBListBox, etc are concerned, these always display the value from the current record in the related dataset. No amount of coding will permit these components to simultneously display different field values on different forms: if they are fed by the same datasource from the same record field, they will display the same value (though of course, the contents of associated lists in the controls, as in the drop-down list of a DBComboBox, may differ between them). This arises from the way TDataSets are designed to operate: they all implement a dataset "cursor" which makes all data-reading and -writing operations operate on a single, "current" record of the dataset and the value of the dataset field which a db-aware component displays is the value in the record the cursor is on.
edited Jan 4 at 22:17
answered Jan 4 at 10:15
MartynAMartynA
21.4k32257
21.4k32257
From what I understand of your last paragraph, the problem is the TDataset itself, not really the TDataSource. I don't want any event connected to these datasets and datasources, they are just sources for LookupComboboxes. And I should have mentionned that I am using DevExpress components in non-SyncMode (the components use an internal cache and selecting a value won't affect the underlying TDataset descendant's cursor). So in this kind of use, it should not induce side-effects/artefacts.
– JC Boggio
Jan 4 at 13:37
I'm not sure what you mean by "the problem": if you mean the fact that all db-aware components connected to the same dataset field will always display the same value, that arises simply because of the way the TDataSet descendants all work, namely they all implement a dataset "cursor" which make all data-reading and -writing operations operate on a single, "current" record of the dataset.
– MartynA
Jan 4 at 15:27
add a comment |
From what I understand of your last paragraph, the problem is the TDataset itself, not really the TDataSource. I don't want any event connected to these datasets and datasources, they are just sources for LookupComboboxes. And I should have mentionned that I am using DevExpress components in non-SyncMode (the components use an internal cache and selecting a value won't affect the underlying TDataset descendant's cursor). So in this kind of use, it should not induce side-effects/artefacts.
– JC Boggio
Jan 4 at 13:37
I'm not sure what you mean by "the problem": if you mean the fact that all db-aware components connected to the same dataset field will always display the same value, that arises simply because of the way the TDataSet descendants all work, namely they all implement a dataset "cursor" which make all data-reading and -writing operations operate on a single, "current" record of the dataset.
– MartynA
Jan 4 at 15:27
From what I understand of your last paragraph, the problem is the TDataset itself, not really the TDataSource. I don't want any event connected to these datasets and datasources, they are just sources for LookupComboboxes. And I should have mentionned that I am using DevExpress components in non-SyncMode (the components use an internal cache and selecting a value won't affect the underlying TDataset descendant's cursor). So in this kind of use, it should not induce side-effects/artefacts.
– JC Boggio
Jan 4 at 13:37
From what I understand of your last paragraph, the problem is the TDataset itself, not really the TDataSource. I don't want any event connected to these datasets and datasources, they are just sources for LookupComboboxes. And I should have mentionned that I am using DevExpress components in non-SyncMode (the components use an internal cache and selecting a value won't affect the underlying TDataset descendant's cursor). So in this kind of use, it should not induce side-effects/artefacts.
– JC Boggio
Jan 4 at 13:37
I'm not sure what you mean by "the problem": if you mean the fact that all db-aware components connected to the same dataset field will always display the same value, that arises simply because of the way the TDataSet descendants all work, namely they all implement a dataset "cursor" which make all data-reading and -writing operations operate on a single, "current" record of the dataset.
– MartynA
Jan 4 at 15:27
I'm not sure what you mean by "the problem": if you mean the fact that all db-aware components connected to the same dataset field will always display the same value, that arises simply because of the way the TDataSet descendants all work, namely they all implement a dataset "cursor" which make all data-reading and -writing operations operate on a single, "current" record of the dataset.
– MartynA
Jan 4 at 15:27
add a comment |
You are asking two questions there. - No problem.
On the usage of the Datasource, absolutely. I have all my TTables, TQuerys and DatSources in the one DataModule aand reference them from multiple Forms with multiple components on each.
On the combobox1 v combobox2 interaction, it will depend on the code behind them. Nominally in the OnChange event.
Ian
MartynA - DBCombobox was not specified, only ComboBox. I prefer not to make assumptions. Had DBCombobox been specified my answer to that part would have been different.
– Ian Branch
Jan 4 at 22:11
Fair enough - I assumed the OP's omission of the TDB prefix was a typo, as he specfically said " if I have two TLookupCombobox ...**using** the same TDataSource" , and they could only use a datasource at all if they were the db-aware type. Anyway, I've edited my answer to avoid saying that I disagree with this onr.
– MartynA
Jan 4 at 22:22
add a comment |
You are asking two questions there. - No problem.
On the usage of the Datasource, absolutely. I have all my TTables, TQuerys and DatSources in the one DataModule aand reference them from multiple Forms with multiple components on each.
On the combobox1 v combobox2 interaction, it will depend on the code behind them. Nominally in the OnChange event.
Ian
MartynA - DBCombobox was not specified, only ComboBox. I prefer not to make assumptions. Had DBCombobox been specified my answer to that part would have been different.
– Ian Branch
Jan 4 at 22:11
Fair enough - I assumed the OP's omission of the TDB prefix was a typo, as he specfically said " if I have two TLookupCombobox ...**using** the same TDataSource" , and they could only use a datasource at all if they were the db-aware type. Anyway, I've edited my answer to avoid saying that I disagree with this onr.
– MartynA
Jan 4 at 22:22
add a comment |
You are asking two questions there. - No problem.
On the usage of the Datasource, absolutely. I have all my TTables, TQuerys and DatSources in the one DataModule aand reference them from multiple Forms with multiple components on each.
On the combobox1 v combobox2 interaction, it will depend on the code behind them. Nominally in the OnChange event.
Ian
You are asking two questions there. - No problem.
On the usage of the Datasource, absolutely. I have all my TTables, TQuerys and DatSources in the one DataModule aand reference them from multiple Forms with multiple components on each.
On the combobox1 v combobox2 interaction, it will depend on the code behind them. Nominally in the OnChange event.
Ian
answered Jan 4 at 1:45
Ian BranchIan Branch
496
496
MartynA - DBCombobox was not specified, only ComboBox. I prefer not to make assumptions. Had DBCombobox been specified my answer to that part would have been different.
– Ian Branch
Jan 4 at 22:11
Fair enough - I assumed the OP's omission of the TDB prefix was a typo, as he specfically said " if I have two TLookupCombobox ...**using** the same TDataSource" , and they could only use a datasource at all if they were the db-aware type. Anyway, I've edited my answer to avoid saying that I disagree with this onr.
– MartynA
Jan 4 at 22:22
add a comment |
MartynA - DBCombobox was not specified, only ComboBox. I prefer not to make assumptions. Had DBCombobox been specified my answer to that part would have been different.
– Ian Branch
Jan 4 at 22:11
Fair enough - I assumed the OP's omission of the TDB prefix was a typo, as he specfically said " if I have two TLookupCombobox ...**using** the same TDataSource" , and they could only use a datasource at all if they were the db-aware type. Anyway, I've edited my answer to avoid saying that I disagree with this onr.
– MartynA
Jan 4 at 22:22
MartynA - DBCombobox was not specified, only ComboBox. I prefer not to make assumptions. Had DBCombobox been specified my answer to that part would have been different.
– Ian Branch
Jan 4 at 22:11
MartynA - DBCombobox was not specified, only ComboBox. I prefer not to make assumptions. Had DBCombobox been specified my answer to that part would have been different.
– Ian Branch
Jan 4 at 22:11
Fair enough - I assumed the OP's omission of the TDB prefix was a typo, as he specfically said " if I have two TLookupCombobox ...**using** the same TDataSource" , and they could only use a datasource at all if they were the db-aware type. Anyway, I've edited my answer to avoid saying that I disagree with this onr.
– MartynA
Jan 4 at 22:22
Fair enough - I assumed the OP's omission of the TDB prefix was a typo, as he specfically said " if I have two TLookupCombobox ...**using** the same TDataSource" , and they could only use a datasource at all if they were the db-aware type. Anyway, I've edited my answer to avoid saying that I disagree with this onr.
– MartynA
Jan 4 at 22:22
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54031649%2fis-it-safe-to-share-a-tdatasource-between-several-controls-at-the-same-time%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
yes, it is safe. but if your application is big, sharing datasources will be a bad thing. it is very hard to maintain in the long run
– Ago
Jan 4 at 8:44