Does anyone have a decent resolution to data layer
handling of stored procedures with inner and outer joins?
handling of stored procedures with inner and outer joins?
-
-
Re: Sql Joins
retrieving the data shouldn't be an issue........
Inserts, updates and deletes...... are a different story....... the SP
almost needs to be a program within itself...... to deal with FIELDS......
and it combines them up into the appropriate SQL statements..... for the
various tables
If you provided just a little more info on what your doing with the join....
it would be easier to assist.........
"Rob Morris" <robertcmorris@ bellsouth.net> wrote in message
news:056001c39c fa$e10edab0$a50 1280a@phx.gbl.. .[color=blue]
> Does anyone have a decent resolution to data layer
> handling of stored procedures with inner and outer joins?[/color]
-
Re: Sql Joins
I agree it shouldn't be an issue ... and thanks for your
response.
Here is the problem, I have several middle-tiers and none
that required so much compatibility with existing "stuff"
as this one. I am dealing with stored procedures that may
have multiple table aliases to the same table. When I
return the data to the object layer I need to identify
fields with the same name uniquely, preferably by the
table alias. There was a way, I think, in ADODB to get
the table aliases. I can not seem to find a way to do
this in ADO.NET.
Any help is appreciated greatly,
- Rob
[color=blue]
>-----Original Message-----
>retrieving the data shouldn't be an issue........
>
>Inserts, updates and deletes...... are a different[/color]
story....... the SP[color=blue]
>almost needs to be a program within itself...... to[/color]
deal with FIELDS......[color=blue]
>and it combines them up into the appropriate SQL[/color]
statements..... for the[color=blue]
>various tables
>
>If you provided just a little more info on what your[/color]
doing with the join....[color=blue]
>it would be easier to assist.........
>
>"Rob Morris" <robertcmorris@ bellsouth.net> wrote in[/color]
message[color=blue]
>news:056001c39 cfa$e10edab0$a5 01280a@phx.gbl. ..[color=green]
>> Does anyone have a decent resolution to data layer
>> handling of stored procedures with inner and outer[/color][/color]
joins?[color=blue]
>
>
>.
>[/color]
Comment
-
Re: Sql Joins
Within the four different DBs that I have played with, when there is naming
issues of the columns, the DBs have resolved it typically with a "1" or
"A/B" attached to the end of the column name......
(Select * from Customer, Orders)... would result in the customerID to be
recalled twice..... hence two columns, different names..... a 1 & 2
....... or an A & B versions..... one from each table
As far as I'm aware, the DB table names are not available as part of the
dataset/datatable structure....
The DB table used to be available through VB6 and ADODB recordsets.... as
long as it was still connected to the database... but lost that as soon as
the recordset crossed over a process boundry (or so that was our
experience).
HTH....... aloha
"Robert Morris" <robertcmorris@ bellsouth.net> wrote in message
news:085101c39d 03$92807260$a10 1280a@phx.gbl.. .[color=blue]
> I agree it shouldn't be an issue ... and thanks for your
> response.
>
> Here is the problem, I have several middle-tiers and none
> that required so much compatibility with existing "stuff"
> as this one. I am dealing with stored procedures that may
> have multiple table aliases to the same table. When I
> return the data to the object layer I need to identify
> fields with the same name uniquely, preferably by the
> table alias. There was a way, I think, in ADODB to get
> the table aliases. I can not seem to find a way to do
> this in ADO.NET.
>
> Any help is appreciated greatly,
> - Rob
>[color=green]
> >-----Original Message-----
> >retrieving the data shouldn't be an issue........
> >
> >Inserts, updates and deletes...... are a different[/color]
> story....... the SP[color=green]
> >almost needs to be a program within itself...... to[/color]
> deal with FIELDS......[color=green]
> >and it combines them up into the appropriate SQL[/color]
> statements..... for the[color=green]
> >various tables
> >
> >If you provided just a little more info on what your[/color]
> doing with the join....[color=green]
> >it would be easier to assist.........
> >
> >"Rob Morris" <robertcmorris@ bellsouth.net> wrote in[/color]
> message[color=green]
> >news:056001c39 cfa$e10edab0$a5 01280a@phx.gbl. ..[color=darkred]
> >> Does anyone have a decent resolution to data layer
> >> handling of stored procedures with inner and outer[/color][/color]
> joins?[color=green]
> >
> >
> >.
> >[/color][/color]
Comment
-
Re: Sql Joins
Steve, Thank you very much, I got the 1,2 thing but I
have a feeling that I am going to have to make an ADODB
call till they can get their act straight, thanks!
[color=blue]
>-----Original Message-----
>Within the four different DBs that I have played with,[/color]
when there is naming[color=blue]
>issues of the columns, the DBs have resolved it[/color]
typically with a "1" or[color=blue]
>"A/B" attached to the end of the column name......
>(Select * from Customer, Orders)... would result in the[/color]
customerID to be[color=blue]
>recalled twice..... hence two columns, different[/color]
names..... a 1 & 2[color=blue]
>....... or an A & B versions..... one from each[/color]
table[color=blue]
>
>As far as I'm aware, the DB table names are not[/color]
available as part of the[color=blue]
>dataset/datatable structure....
>
>The DB table used to be available through VB6 and ADODB[/color]
recordsets.... as[color=blue]
>long as it was still connected to the database... but[/color]
lost that as soon as[color=blue]
>the recordset crossed over a process boundry (or so that[/color]
was our[color=blue]
>experience).
>
>HTH....... aloha
>
>"Robert Morris" <robertcmorris@ bellsouth.net> wrote in[/color]
message[color=blue]
>news:085101c39 d03$92807260$a1 01280a@phx.gbl. ..[color=green]
>> I agree it shouldn't be an issue ... and thanks for[/color][/color]
your[color=blue][color=green]
>> response.
>>
>> Here is the problem, I have several middle-tiers and[/color][/color]
none[color=blue][color=green]
>> that required so much compatibility with[/color][/color]
existing "stuff"[color=blue][color=green]
>> as this one. I am dealing with stored procedures that[/color][/color]
may[color=blue][color=green]
>> have multiple table aliases to the same table. When I
>> return the data to the object layer I need to identify
>> fields with the same name uniquely, preferably by the
>> table alias. There was a way, I think, in ADODB to get
>> the table aliases. I can not seem to find a way to do
>> this in ADO.NET.
>>
>> Any help is appreciated greatly,
>> - Rob
>>[color=darkred]
>> >-----Original Message-----
>> >retrieving the data shouldn't be an issue........
>> >
>> >Inserts, updates and deletes...... are a different[/color]
>> story....... the SP[color=darkred]
>> >almost needs to be a program within itself...... to[/color]
>> deal with FIELDS......[color=darkred]
>> >and it combines them up into the appropriate SQL[/color]
>> statements..... for the[color=darkred]
>> >various tables
>> >
>> >If you provided just a little more info on what your[/color]
>> doing with the join....[color=darkred]
>> >it would be easier to assist.........
>> >
>> >"Rob Morris" <robertcmorris@ bellsouth.net> wrote in[/color]
>> message[color=darkred]
>> >news:056001c39 cfa$e10edab0$a5 01280a@phx.gbl. ..
>> >> Does anyone have a decent resolution to data layer
>> >> handling of stored procedures with inner and outer[/color]
>> joins?[color=darkred]
>> >
>> >
>> >.
>> >[/color][/color]
>
>
>.
>[/color]
Comment
Comment