Typed Datasets

[=?Utf-8?B?Um9iZXJ0IFNtaXRo?=]

Hi,
I have a problem whereby I have one form dealing with one of two
typed datasets with almost all the same column names except two, depenind on
which option the user selects.

at the moment I have if statements like the following that set the value of
form fields etc, depeninding on the selected value

if (selectedtab = "Agency")
{
txtfield.Name = AgencyDataset.A gencyTable[currentindex].AgencyName ;
}else if (selectedbat = "Advertiser ") then
{
txtfield.Name =
AdvertiserDatas et.AdvertiserTa ble[currentindex].AdvertiserName ;
}
do you know of a smarter way of doing this so I don't have to continually do
if statements to determine which dataset to use and also to avoid getting
type casting errors.
Thanx in advance
Robert

[Roger Frost]

Re: Typed Datasets

"Robert Smith" <RobertSmith@di scussions.micro soft.comwrote in message
news:EE24F63A-8F39-4407-814E-A0A3D1E8FDD8@mi crosoft.com...

Thanks Roger,
Will that not cause issues when updating the dataset when
the name of the dataset column does not match the column in the underlying
database name.
>
I tried using select AgencyName as Name etc, and then updating the dataset
but haven't changed the actual dataset column names;
>
>

I was just thinking that if your tables are already 1 column name from being
of identical schema as it is, and they hold the same basic information: a
name, you may as well rename the columns to simplify data access.

Preferably (in this case), I would combine both the tables into one standard
table (like ContactInfo for example) and add separate tables for Agencies
and Advertisers that have a foreign key relationship with ContactInfo. This
makes much more sense to me, but I have limited knowledge about your system
to go on.

On the other hand, if this database is already in use these changes will
certainly break other client applications.

The good news is you can get around this without breaking existing tools by
leaving them as they are and adding a identical column alias to each table's
....Name column.

You just need to think about what you're trying to do now and who (if
anyone) is already relying on this database. There are many ways to
simplify your Dataset dilemma, the route you take will be determined by the
issues listed above, and many others.

Just think it through (and _always_ backup before you go wild with schema
changes:) )


--
Roger Frost
"Logic Is Syntax Independent"

[=?Utf-8?B?Um9iZXJ0IFNtaXRo?=]

Re: Typed Datasets

Thanks Roger,
Actually the Identifer key also have different names. One is
AgencyId and the other is AdvertiserId. Does your theory still hold true
knowing this information.


"Roger Frost" wrote:

"Robert Smith" <RobertSmith@di scussions.micro soft.comwrote in message
news:EE24F63A-8F39-4407-814E-A0A3D1E8FDD8@mi crosoft.com...

Thanks Roger,
Will that not cause issues when updating the dataset when
the name of the dataset column does not match the column in the underlying
database name.

I tried using select AgencyName as Name etc, and then updating the dataset
but haven't changed the actual dataset column names;

>
I was just thinking that if your tables are already 1 column name from being
of identical schema as it is, and they hold the same basic information: a
name, you may as well rename the columns to simplify data access.
>
Preferably (in this case), I would combine both the tables into one standard
table (like ContactInfo for example) and add separate tables for Agencies
and Advertisers that have a foreign key relationship with ContactInfo. This
makes much more sense to me, but I have limited knowledge about your system
to go on.
>
On the other hand, if this database is already in use these changes will
certainly break other client applications.
>
The good news is you can get around this without breaking existing tools by
leaving them as they are and adding a identical column alias to each table's
...Name column.
>
You just need to think about what you're trying to do now and who (if
anyone) is already relying on this database. There are many ways to
simplify your Dataset dilemma, the route you take will be determined by the
issues listed above, and many others.
>
Just think it through (and _always_ backup before you go wild with schema
changes:) )
>
>
--
Roger Frost
"Logic Is Syntax Independent"
>