Basic OLAP require !

Hi Champs!!
I am totally new in OLAP and want know more prior to start...pls tell me know the difference between these..
Regular/Virtual/Linked cubes..
Star schema/ snow flake/ parent-child/ virtual dimension/ mining model
Thanks in advance
-Deepak Kumar.Cubes
Cube consist of dimensions on ehich to analyse the data.

1>Regular Cube
A regular cube is based on tables in the databases specified in
the data sources of the cube's partitions

2>Virtual Cube
created with one or more regular cubes.
A virtual cube is a combination of multiple cubes in one logical
cube, somewhat like a relational database view that combines other
views and tables.Thus it contains measures from the related cubes.

3> Linked Cube
A linked cube is based on another cube that is defined and stored
on another Analysis server. To end users, linked cubes appear and
function like regular cubes. By using linked cubes, you can create,
store, and maintain a cube on one Analysis server while the cube is
also available as linked cubes on multiple Analysis servers

----------------------
**Dimension
1>Regular Dimension
every cube must has atleast one dimension.It is the default dimension.
dimensions have associated aggregation data in the cubes in which they
are used. A regular dimension contains a number of levels equal to the
number of columns selected during its definition

2>Virtual Dimension
Based on other dimensions.
A virtual dimension is a logical dimension based on the columns from
a physical dimension

3>Parent Child Dimension
A parent-child dimension is based on two dimension table columns that
together define the lineage relationships among the members of the
dimension. One column, called the member key column, identifies each
member; the other column, called the parent key column, identifies the
parent of each member. This information is used to create parent-child
links, which are then combined into a single member hierarchy that
represents a single meta data level.

For example, in the Employee table, the column that identifies each
member is Employee_Number. The column that identifies the parent of
each member is Manager_Employee_Number
----------------------
**Mining Model
A mining model enables you to analyze your data for patterns and to make
predictions based on the patterns. You can create a mining model from a
relational schema or a cube, and you can store output from the model in
a tabular column, a cube dimension, or a mining model diagram.

----------------------

**Star Schema
Star Schema: A single dimension table

Select to create a regular dimension based on a single dimension table.
The depth of the dimension depends on the number of levels you select
in a later step. Each level is derived from a column.
When the dimension is added to a cube, the dimension table joins
to the fact table. If each of the cube's dimensions is based on a
single table, the cube has a star schema.

**Snowflake Schema: Multiple, related dimension tables

Select to create a regular dimension based on multiple, joined dimension
tables. The depth of the dimension depends on the number of levels you
select in a later step. Each level is derived from a column.

When the dimension is added to a cube, only one of its dimension
tables joins to the fact table. Therefore, the cube has a snowflake schema.

Regards
Praveen Kumar Pandey

CoVisible Soltuions (http://www.covisible.com)

bad results from linked server to oracle

Using an openquery select statement against a linked server to oracle is
consistently yielding an incomplete result set. Using the Oracle Client, 225
records are returned, yet the SQL Server 2000 linked server returns only 126
records. Both statements were run using the same security credentials. The
linked server is connected to Oracle via odbc and as a test, i ran the same
statement against the same ODBC DSN in Access and did get the correct results.
Therefore the problem does not appear to be with the ODBC driver but with the
linked server itself.
Here is a representation of the tests i have done thus far:
in Sql server i am accessing the linked server using the OPENQUERY statement
as follows:
SELECT *
FROM OPENQUERY(oracledb, 'SELECT *
FROM ORACLETABLE') Rowset_1
running this statement has yielded 126 records
from ms access using the same ODBC system dsn i am getting 225 records with
this statement:SELECT *
FROM ORACLETABLE
and from the SQL Plus Oracle client i am getting 225 records with the
following statement:SELECT *
FROM ORACLETABLE;
That is a bit weird. Have you tried using a different table? OPENROWSET
(as a test)? Drop/recreate the LS to Oracle?
Might look here as well:
How to set up and troubleshoot a linked server to Oracle in SQL Server
http://support.microsoft.com/default...b;en-us;280106
HTH
Jerry
"inteldsn via droptable.com" <u15033@.uwe> wrote in message
news:56172ad97fe9e@.uwe...
> Using an openquery select statement against a linked server to oracle is
> consistently yielding an incomplete result set. Using the Oracle Client,
> 225
> records are returned, yet the SQL Server 2000 linked server returns only
> 126
> records. Both statements were run using the same security credentials. The
> linked server is connected to Oracle via odbc and as a test, i ran the
> same
> statement against the same ODBC DSN in Access and did get the correct
> results.
> Therefore the problem does not appear to be with the ODBC driver but with
> the
> linked server itself.
> Here is a representation of the tests i have done thus far:
> in Sql server i am accessing the linked server using the OPENQUERY
> statement
> as follows:
> SELECT *
> FROM OPENQUERY(oracledb, 'SELECT *
> FROM ORACLETABLE') Rowset_1
> running this statement has yielded 126 records
> from ms access using the same ODBC system dsn i am getting 225 records
> with
> this statement:SELECT *
> FROM ORACLETABLE
> and from the SQL Plus Oracle client i am getting 225 records with the
> following statement:SELECT *
> FROM ORACLETABLE;
|||good suggestion. i did look at that msdn article earlier, i have not been
able to check all of the tables yet, but so far this behavior is not on all
of the tables. update from testing: if i run select * from openquery ('select
count(*) from oracletable') recordset_1 I do get the magic number 225.
I have also queried using a where statement for one of the missing records
and the missing record DOES return. so why it does not return using select *
is the mystery.
Jerry Spivey wrote:
>That is a bit weird. Have you tried using a different table? OPENROWSET
>(as a test)? Drop/recreate the LS to Oracle?
>Might look here as well:
>How to set up and troubleshoot a linked server to Oracle in SQL Server
>http://support.microsoft.com/default...b;en-us;280106
>HTH
>Jerry
|||NULLs on the other end? Might try COUNT(COLUMN) just to see what it
returns. I'd be looking at the column values for a row that doesn't come
back without the WHERE as compared to one that does.
HTH
Jerry
"inteldsn via droptable.com" <u15033@.uwe> wrote in message
news:56175b9b94e48@.uwe...[vbcol=seagreen]
> good suggestion. i did look at that msdn article earlier, i have not been
> able to check all of the tables yet, but so far this behavior is not on
> all
> of the tables. update from testing: if i run select * from openquery
> ('select
> count(*) from oracletable') recordset_1 I do get the magic number 225.
> I have also queried using a where statement for one of the missing records
> and the missing record DOES return. so why it does not return using select
> *
> is the mystery.
>
> Jerry Spivey wrote:
|||Jerry,
no nulls on the other end. SELECT *
FROM OPENQUERY(oracledb, 'SELECTcount (*)
FROM ORACLETABLE') Rowset_1 yields a result of 255 just as it should.
if i put a where clause on it, i can get any of the 255 actual records in the
table, but i can't get them all from a general select statement.
Jerry Spivey wrote:[vbcol=seagreen]
>NULLs on the other end? Might try COUNT(COLUMN) just to see what it
>returns. I'd be looking at the column values for a row that doesn't come
>back without the WHERE as compared to one that does.
>HTH
>Jerry
>[quoted text clipped - 19 lines]
|||TJI: What is the possibility that the table on the Oracle side does not have
a unique key and what you are seeing are the unique records?
I have seen that OpenQuery/OLEDB has a preference for unique identifiers.
Joseph R.P. Maloney, CSP,CCP,CDP
"inteldsn via droptable.com" wrote:

> Jerry,
> no nulls on the other end. SELECT *
> FROM OPENQUERY(oracledb, 'SELECTcount (*)
> FROM ORACLETABLE') Rowset_1 yields a result of 255 just as it should.
> if i put a where clause on it, i can get any of the 255 actual records in the
> table, but i can't get them all from a general select statement.
>
> Jerry Spivey wrote:
>
|||the results list is missing 99 unique new records, so that is not the answer.
WORKAROUND: MS techs were unable to solve this either, but what we did do was
to abandon using the provider for odbc to create the linked server. Here's
what i have learned so far. using the microsoft provider for odbc driver to
create the linked server, the linked server fails to provide consistently
correct results. I switched to using the provider for ole db for oracle and i
am now getting good results. However, you have to download the provider for
ole db from the oracle site in order to install this and get it working if
your oracle installation is anything more recent than 8.2. there are other
dependencies requiring additional software and configuration if you need to
use distributed transactions as well.
so basically, this is a flaw in the way sql server 2000 handles linked
servers created through the odbc provider.
jrpm wrote:[vbcol=seagreen]
>TJI: What is the possibility that the table on the Oracle side does not have
>a unique key and what you are seeing are the unique records?
>I have seen that OpenQuery/OLEDB has a preference for unique identifiers.
>[quoted text clipped - 17 lines]
Message posted via http://www.droptable.com
|||UGH!!! I should have asked you that. I had an issue using the ODBC driver
for ORACLE (similar but not the same) at a submarine base consult one time.
I dropped the LS and recreated it using the OLE-DB provider for ORACLE and
it worked fine.
Sorry didn't think of that sooner.
Jerry
"inteldsn via droptable.com" <u15033@.uwe> wrote in message
news:5623fa2fc9ebd@.uwe...
> the results list is missing 99 unique new records, so that is not the
> answer.
>
> WORKAROUND: MS techs were unable to solve this either, but what we did do
> was
> to abandon using the provider for odbc to create the linked server. Here's
> what i have learned so far. using the microsoft provider for odbc driver
> to
> create the linked server, the linked server fails to provide consistently
> correct results. I switched to using the provider for ole db for oracle
> and i
> am now getting good results. However, you have to download the provider
> for
> ole db from the oracle site in order to install this and get it working
> if
> your oracle installation is anything more recent than 8.2. there are other
> dependencies requiring additional software and configuration if you need
> to
> use distributed transactions as well.
> so basically, this is a flaw in the way sql server 2000 handles linked
> servers created through the odbc provider.
> jrpm wrote:
>
> --
> Message posted via http://www.droptable.com

bad results from linked server to oracle

Using an openquery select statement against a linked server to oracle is
consistently yielding an incomplete result set. Using the Oracle Client, 225
records are returned, yet the SQL Server 2000 linked server returns only 126
records. Both statements were run using the same security credentials. The
linked server is connected to Oracle via odbc and as a test, i ran the same
statement against the same ODBC DSN in Access and did get the correct result
s.
Therefore the problem does not appear to be with the ODBC driver but with th
e
linked server itself.
Here is a representation of the tests i have done thus far:
in Sql server i am accessing the linked server using the OPENQUERY statement
as follows:
SELECT *
FROM OPENQUERY(oracledb, 'SELECT *
FROM ORACLETABLE') Rowset_1
running this statement has yielded 126 records
from ms access using the same ODBC system dsn i am getting 225 records with
this statement:SELECT *
FROM ORACLETABLE
and from the SQL Plus Oracle client i am getting 225 records with the
following statement:SELECT *
FROM ORACLETABLE;That is a bit weird. Have you tried using a different table? OPENROWSET
(as a test)? Drop/recreate the LS to Oracle?
Might look here as well:
How to set up and troubleshoot a linked server to Oracle in SQL Server
http://support.microsoft.com/defaul...kb;en-us;280106
HTH
Jerry
"inteldsn via droptable.com" <u15033@.uwe> wrote in message
news:56172ad97fe9e@.uwe...
> Using an openquery select statement against a linked server to oracle is
> consistently yielding an incomplete result set. Using the Oracle Client,
> 225
> records are returned, yet the SQL Server 2000 linked server returns only
> 126
> records. Both statements were run using the same security credentials. The
> linked server is connected to Oracle via odbc and as a test, i ran the
> same
> statement against the same ODBC DSN in Access and did get the correct
> results.
> Therefore the problem does not appear to be with the ODBC driver but with
> the
> linked server itself.
> Here is a representation of the tests i have done thus far:
> in Sql server i am accessing the linked server using the OPENQUERY
> statement
> as follows:
> SELECT *
> FROM OPENQUERY(oracledb, 'SELECT *
> FROM ORACLETABLE') Rowset_1
> running this statement has yielded 126 records
> from ms access using the same ODBC system dsn i am getting 225 records
> with
> this statement:SELECT *
> FROM ORACLETABLE
> and from the SQL Plus Oracle client i am getting 225 records with the
> following statement:SELECT *
> FROM ORACLETABLE;|||good suggestion. i did look at that msdn article earlier, i have not been
able to check all of the tables yet, but so far this behavior is not on all
of the tables. update from testing: if i run select * from openquery ('selec
t
count(*) from oracletable') recordset_1 I do get the magic number 225.
I have also queried using a where statement for one of the missing records
and the missing record DOES return. so why it does not return using select *
is the mystery.
Jerry Spivey wrote:
>That is a bit weird. Have you tried using a different table? OPENROWSET
>(as a test)? Drop/recreate the LS to Oracle?
>Might look here as well:
>How to set up and troubleshoot a linked server to Oracle in SQL Server
>http://support.microsoft.com/defaul...kb;en-us;280106
>HTH
>Jerry|||NULLs on the other end? Might try COUNT(COLUMN) just to see what it
returns. I'd be looking at the column values for a row that doesn't come
back without the WHERE as compared to one that does.
HTH
Jerry
"inteldsn via droptable.com" <u15033@.uwe> wrote in message
news:56175b9b94e48@.uwe...[vbcol=seagreen]
> good suggestion. i did look at that msdn article earlier, i have not been
> able to check all of the tables yet, but so far this behavior is not on
> all
> of the tables. update from testing: if i run select * from openquery
> ('select
> count(*) from oracletable') recordset_1 I do get the magic number 225.
> I have also queried using a where statement for one of the missing records
> and the missing record DOES return. so why it does not return using select
> *
> is the mystery.
>
> Jerry Spivey wrote:|||Jerry,
no nulls on the other end. SELECT *
FROM OPENQUERY(oracledb, 'SELECTcount (*)
FROM ORACLETABLE') Rowset_1 yields a result of 255 just as it should.
if i put a where clause on it, i can get any of the 255 actual records in th
e
table, but i can't get them all from a general select statement.
Jerry Spivey wrote:[vbcol=seagreen]
>NULLs on the other end? Might try COUNT(COLUMN) just to see what it
>returns. I'd be looking at the column values for a row that doesn't come
>back without the WHERE as compared to one that does.
>HTH
>Jerry
>[quoted text clipped - 19 lines]|||TJI: What is the possibility that the table on the Oracle side does not have
a unique key and what you are seeing are the unique records?
I have seen that OpenQuery/OLEDB has a preference for unique identifiers.
--
Joseph R.P. Maloney, CSP,CCP,CDP
"inteldsn via droptable.com" wrote:

> Jerry,
> no nulls on the other end. SELECT *
> FROM OPENQUERY(oracledb, 'SELECTcount (*)
> FROM ORACLETABLE') Rowset_1 yields a result of 255 just as it should.
> if i put a where clause on it, i can get any of the 255 actual records in
the
> table, but i can't get them all from a general select statement.
>
> Jerry Spivey wrote:
>|||the results list is missing 99 unique new records, so that is not the answer
.
WORKAROUND: MS techs were unable to solve this either, but what we did do wa
s
to abandon using the provider for odbc to create the linked server. Here's
what i have learned so far. using the microsoft provider for odbc driver to
create the linked server, the linked server fails to provide consistently
correct results. I switched to using the provider for ole db for oracle and
i
am now getting good results. However, you have to download the provider for
ole db from the oracle site in order to install this and get it working if
your oracle installation is anything more recent than 8.2. there are other
dependencies requiring additional software and configuration if you need to
use distributed transactions as well.
so basically, this is a flaw in the way sql server 2000 handles linked
servers created through the odbc provider.
jrpm wrote:[vbcol=seagreen]
>TJI: What is the possibility that the table on the Oracle side does not hav
e
>a unique key and what you are seeing are the unique records?
>I have seen that OpenQuery/OLEDB has a preference for unique identifiers.
>[quoted text clipped - 17 lines]
Message posted via http://www.droptable.com|||UGH!!! I should have asked you that. I had an issue using the ODBC driver
for ORACLE (similar but not the same) at a submarine base consult one time.
I dropped the LS and recreated it using the OLE-DB provider for ORACLE and
it worked fine.
Sorry didn't think of that sooner.
Jerry
"inteldsn via droptable.com" <u15033@.uwe> wrote in message
news:5623fa2fc9ebd@.uwe...
> the results list is missing 99 unique new records, so that is not the
> answer.
>
> WORKAROUND: MS techs were unable to solve this either, but what we did do
> was
> to abandon using the provider for odbc to create the linked server. Here's
> what i have learned so far. using the microsoft provider for odbc driver
> to
> create the linked server, the linked server fails to provide consistently
> correct results. I switched to using the provider for ole db for oracle
> and i
> am now getting good results. However, you have to download the provider
> for
> ole db from the oracle site in order to install this and get it working
> if
> your oracle installation is anything more recent than 8.2. there are other
> dependencies requiring additional software and configuration if you need
> to
> use distributed transactions as well.
> so basically, this is a flaw in the way sql server 2000 handles linked
> servers created through the odbc provider.
> jrpm wrote:
>
> --
> Message posted via http://www.droptable.com

bad results from linked server to oracle

Using an openquery select statement against a linked server to oracle is
consistently yielding an incomplete result set. Using the Oracle Client, 225
records are returned, yet the SQL Server 2000 linked server returns only 126
records. Both statements were run using the same security credentials. The
linked server is connected to Oracle via odbc and as a test, i ran the same
statement against the same ODBC DSN in Access and did get the correct results.
Therefore the problem does not appear to be with the ODBC driver but with the
linked server itself.
Here is a representation of the tests i have done thus far:
in Sql server i am accessing the linked server using the OPENQUERY statement
as follows:
SELECT *
FROM OPENQUERY(oracledb, 'SELECT *
FROM ORACLETABLE') Rowset_1
running this statement has yielded 126 records
from ms access using the same ODBC system dsn i am getting 225 records with
this statement:SELECT *
FROM ORACLETABLE
and from the SQL Plus Oracle client i am getting 225 records with the
following statement:SELECT *
FROM ORACLETABLE;That is a bit weird. Have you tried using a different table? OPENROWSET
(as a test)? Drop/recreate the LS to Oracle?
Might look here as well:
How to set up and troubleshoot a linked server to Oracle in SQL Server
http://support.microsoft.com/default.aspx?scid=kb;en-us;280106
HTH
Jerry
"inteldsn via SQLMonster.com" <u15033@.uwe> wrote in message
news:56172ad97fe9e@.uwe...
> Using an openquery select statement against a linked server to oracle is
> consistently yielding an incomplete result set. Using the Oracle Client,
> 225
> records are returned, yet the SQL Server 2000 linked server returns only
> 126
> records. Both statements were run using the same security credentials. The
> linked server is connected to Oracle via odbc and as a test, i ran the
> same
> statement against the same ODBC DSN in Access and did get the correct
> results.
> Therefore the problem does not appear to be with the ODBC driver but with
> the
> linked server itself.
> Here is a representation of the tests i have done thus far:
> in Sql server i am accessing the linked server using the OPENQUERY
> statement
> as follows:
> SELECT *
> FROM OPENQUERY(oracledb, 'SELECT *
> FROM ORACLETABLE') Rowset_1
> running this statement has yielded 126 records
> from ms access using the same ODBC system dsn i am getting 225 records
> with
> this statement:SELECT *
> FROM ORACLETABLE
> and from the SQL Plus Oracle client i am getting 225 records with the
> following statement:SELECT *
> FROM ORACLETABLE;|||good suggestion. i did look at that msdn article earlier, i have not been
able to check all of the tables yet, but so far this behavior is not on all
of the tables. update from testing: if i run select * from openquery ('select
count(*) from oracletable') recordset_1 I do get the magic number 225.
I have also queried using a where statement for one of the missing records
and the missing record DOES return. so why it does not return using select *
is the mystery.
Jerry Spivey wrote:
>That is a bit weird. Have you tried using a different table? OPENROWSET
>(as a test)? Drop/recreate the LS to Oracle?
>Might look here as well:
>How to set up and troubleshoot a linked server to Oracle in SQL Server
>http://support.microsoft.com/default.aspx?scid=kb;en-us;280106
>HTH
>Jerry|||NULLs on the other end? Might try COUNT(COLUMN) just to see what it
returns. I'd be looking at the column values for a row that doesn't come
back without the WHERE as compared to one that does.
HTH
Jerry
"inteldsn via SQLMonster.com" <u15033@.uwe> wrote in message
news:56175b9b94e48@.uwe...
> good suggestion. i did look at that msdn article earlier, i have not been
> able to check all of the tables yet, but so far this behavior is not on
> all
> of the tables. update from testing: if i run select * from openquery
> ('select
> count(*) from oracletable') recordset_1 I do get the magic number 225.
> I have also queried using a where statement for one of the missing records
> and the missing record DOES return. so why it does not return using select
> *
> is the mystery.
>
> Jerry Spivey wrote:
>>That is a bit weird. Have you tried using a different table? OPENROWSET
>>(as a test)? Drop/recreate the LS to Oracle?
>>Might look here as well:
>>How to set up and troubleshoot a linked server to Oracle in SQL Server
>>http://support.microsoft.com/default.aspx?scid=kb;en-us;280106
>>HTH
>>Jerry|||Jerry,
no nulls on the other end. SELECT *
FROM OPENQUERY(oracledb, 'SELECTcount (*)
FROM ORACLETABLE') Rowset_1 yields a result of 255 just as it should.
if i put a where clause on it, i can get any of the 255 actual records in the
table, but i can't get them all from a general select statement.
Jerry Spivey wrote:
>NULLs on the other end? Might try COUNT(COLUMN) just to see what it
>returns. I'd be looking at the column values for a row that doesn't come
>back without the WHERE as compared to one that does.
>HTH
>Jerry
>> good suggestion. i did look at that msdn article earlier, i have not been
>> able to check all of the tables yet, but so far this behavior is not on
>[quoted text clipped - 19 lines]
>>Jerry|||TJI: What is the possibility that the table on the Oracle side does not have
a unique key and what you are seeing are the unique records?
I have seen that OpenQuery/OLEDB has a preference for unique identifiers.
--
Joseph R.P. Maloney, CSP,CCP,CDP
"inteldsn via SQLMonster.com" wrote:
> Jerry,
> no nulls on the other end. SELECT *
> FROM OPENQUERY(oracledb, 'SELECTcount (*)
> FROM ORACLETABLE') Rowset_1 yields a result of 255 just as it should.
> if i put a where clause on it, i can get any of the 255 actual records in the
> table, but i can't get them all from a general select statement.
>
> Jerry Spivey wrote:
> >NULLs on the other end? Might try COUNT(COLUMN) just to see what it
> >returns. I'd be looking at the column values for a row that doesn't come
> >back without the WHERE as compared to one that does.
> >
> >HTH
> >
> >Jerry
> >> good suggestion. i did look at that msdn article earlier, i have not been
> >> able to check all of the tables yet, but so far this behavior is not on
> >[quoted text clipped - 19 lines]
> >>
> >>Jerry
>|||the results list is missing 99 unique new records, so that is not the answer.
WORKAROUND: MS techs were unable to solve this either, but what we did do was
to abandon using the provider for odbc to create the linked server. Here's
what i have learned so far. using the microsoft provider for odbc driver to
create the linked server, the linked server fails to provide consistently
correct results. I switched to using the provider for ole db for oracle and i
am now getting good results. However, you have to download the provider for
ole db from the oracle site in order to install this and get it working if
your oracle installation is anything more recent than 8.2. there are other
dependencies requiring additional software and configuration if you need to
use distributed transactions as well.
so basically, this is a flaw in the way sql server 2000 handles linked
servers created through the odbc provider.
jrpm wrote:
>TJI: What is the possibility that the table on the Oracle side does not have
>a unique key and what you are seeing are the unique records?
>I have seen that OpenQuery/OLEDB has a preference for unique identifiers.
>> Jerry,
>[quoted text clipped - 17 lines]
>> >>
>> >>Jerry
Message posted via http://www.sqlmonster.com|||UGH!!! I should have asked you that. I had an issue using the ODBC driver
for ORACLE (similar but not the same) at a submarine base consult one time.
I dropped the LS and recreated it using the OLE-DB provider for ORACLE and
it worked fine.
Sorry didn't think of that sooner.
Jerry
"inteldsn via SQLMonster.com" <u15033@.uwe> wrote in message
news:5623fa2fc9ebd@.uwe...
> the results list is missing 99 unique new records, so that is not the
> answer.
>
> WORKAROUND: MS techs were unable to solve this either, but what we did do
> was
> to abandon using the provider for odbc to create the linked server. Here's
> what i have learned so far. using the microsoft provider for odbc driver
> to
> create the linked server, the linked server fails to provide consistently
> correct results. I switched to using the provider for ole db for oracle
> and i
> am now getting good results. However, you have to download the provider
> for
> ole db from the oracle site in order to install this and get it working
> if
> your oracle installation is anything more recent than 8.2. there are other
> dependencies requiring additional software and configuration if you need
> to
> use distributed transactions as well.
> so basically, this is a flaw in the way sql server 2000 handles linked
> servers created through the odbc provider.
> jrpm wrote:
>>TJI: What is the possibility that the table on the Oracle side does not
>>have
>>a unique key and what you are seeing are the unique records?
>>I have seen that OpenQuery/OLEDB has a preference for unique identifiers.
>> Jerry,
>>[quoted text clipped - 17 lines]
>> >>
>> >>Jerry
>
> --
> Message posted via http://www.sqlmonster.com