Hi all,
I am facing one problem while getting data from stored procedure into
.net application in dataset.
I have two tables say table1 and table2 in which i am continuously
adding data. When i am adding data to table1 same time i am adding data
to table2. This whole process is done through some other application
and not through my application.
But i have one stored procedure which is returing me data from table1
and table2. My logic is i am getting data from table1 into temp table(i
have some more condition for that purpose i need temp table) and then
for those records which are there in temp table i am finding its
equivalent entry in table2. means i should nearly get data same from
both the table.
But what is happening is when i am running same queries which i am
using in sp through query analyzer it is giving me proper resule. Bue
when i try to run those sp and store result of those sp into dataset i
am not getting all records at the same time.
So my question is why this is happening. Is is like that if some other
applications are updating those table then i can't retrieve those
records.
Please clear me if i am wrong.
Thanks in advance.sounds like a concurrency issue.
Please google or BoL for concurrency, locking, blocking, deadlocs and
phantom updates.
"Archana" wrote:
> Hi all,
> I am facing one problem while getting data from stored procedure into
> ..net application in dataset.
> I have two tables say table1 and table2 in which i am continuously
> adding data. When i am adding data to table1 same time i am adding data
> to table2. This whole process is done through some other application
> and not through my application.
> But i have one stored procedure which is returing me data from table1
> and table2. My logic is i am getting data from table1 into temp table(i
> have some more condition for that purpose i need temp table) and then
> for those records which are there in temp table i am finding its
> equivalent entry in table2. means i should nearly get data same from
> both the table.
> But what is happening is when i am running same queries which i am
> using in sp through query analyzer it is giving me proper resule. Bue
> when i try to run those sp and store result of those sp into dataset i
> am not getting all records at the same time.
> So my question is why this is happening. Is is like that if some other
> applications are updating those table then i can't retrieve those
> records.
> Please clear me if i am wrong.
> Thanks in advance.
>
Showing posts with label tables. Show all posts
Showing posts with label tables. Show all posts
Wednesday, March 28, 2012
Friday, March 23, 2012
question on upper bound primary key of type int
I have several tables in a deployed database in which the primary key is of type int, and autoincrements by 1 each time a record is added. My question is, since ints are 32-bit, what happens when its value reaches 4,294,967,296? I know that seems like an extrememly large amount of records, but when we imported the data into the database it started at key value 1,000,000. I don't know how to make it use lower numbers which are currently not being used (numbers below 1,000,000), and I am worried I will have problems when I reach the upper bound. What kind of problems could this cause? Should I change the primary key's type?
Thanks!
the upper bound is somewhere around 2.1 bill. Yes when you reach that limit your application will fail. You cannot insert any new data. You could put some alert in place to identify or predict when the storm is coming. you could create a job that gets the MAX(ID) every week and you can monitor the growth of the table. Once the ID reaches closer to 2 bil you can increase your frequency of monitoring. To fix it, you need modify the column and change it to BigInt. Please do not even bother to try ALTER TABLE...ALTER COLUMN...the server will hang.|||Ok, I'll just modify the primary key type. Thanks for the response.sqlquestion on temporary tables
I have a stored procedure that creates a temporary table, populates it
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
JoeIf you are populating the table with just one row, then use a table variable
instead.
AMB
"joseph.fanelli@.vba.va.gov" wrote:
> I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>|||If you are only populating with one row then chances are you can do this
without a temp table. But to answer your question no others can not see
this. But you might want to do as Alejandro says and use a table variable
instead.
Andrew J. Kelly SQL MVP
<joseph.fanelli@.vba.va.gov> wrote in message
news:1113844980.325249.265010@.l41g2000cwc.googlegroups.com...
>I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>|||Why even use a temporary table?
Declare variables, populate them, then return a recorset:
select @.variable1 as ..., @.variable2 as ... @.variable3 as ... etc.
<joseph.fanelli@.vba.va.gov> wrote in message
news:1113844980.325249.265010@.l41g2000cwc.googlegroups.com...
>I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>|||Andrew,
I did not think about it, but yes, better to use an output parameter. What
about a connection taken from the pool, if the sp does not drop the temporar
y
table explicitly, and uses this code to create it:
if object_id('tempdb..#temptbl') is null
create table #temptbl ...
...
then next time the sp is executed using the same connection, a row inserted
by previous execution can be selected, correct?
AMB
"Andrew J. Kelly" wrote:
> If you are only populating with one row then chances are you can do this
> without a temp table. But to answer your question no others can not see
> this. But you might want to do as Alejandro says and use a table variable
> instead.
> --
> Andrew J. Kelly SQL MVP
>
> <joseph.fanelli@.vba.va.gov> wrote in message
> news:1113844980.325249.265010@.l41g2000cwc.googlegroups.com...
>
>|||If they are using connection pooling and follow the proper procedures a
sp_resetconnection is called that will clean up any such things and put the
connection settings back to the proper settings. Normally a temp table
created in a sp will go out of scope when the sp is completed as well. It
is only if they created the temp table outside of a sp that it will hang
around.
Andrew J. Kelly SQL MVP
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:8C7B0F8B-12B7-49F0-818B-F39C2415C8FE@.microsoft.com...
> Andrew,
> I did not think about it, but yes, better to use an output parameter. What
> about a connection taken from the pool, if the sp does not drop the
> temporary
> table explicitly, and uses this code to create it:
> if object_id('tempdb..#temptbl') is null
> create table #temptbl ...
> ...
> then next time the sp is executed using the same connection, a row
> inserted
> by previous execution can be selected, correct?
>
> AMB
> "Andrew J. Kelly" wrote:
>|||Andrew,
You are right, the temporary table goes out of scope when the sp has
finished. I wonder what kind of cleaning is done by sp_resetconnection, I ca
n
not find anything about it in the BOL.
Thanks,
AMB
"Andrew J. Kelly" wrote:
> If they are using connection pooling and follow the proper procedures a
> sp_resetconnection is called that will clean up any such things and put th
e
> connection settings back to the proper settings. Normally a temp table
> created in a sp will go out of scope when the sp is completed as well. It
> is only if they created the temp table outside of a sp that it will hang
> around.
> --
> Andrew J. Kelly SQL MVP
>
> "Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in messag
e
> news:8C7B0F8B-12B7-49F0-818B-F39C2415C8FE@.microsoft.com...
>
>
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
JoeIf you are populating the table with just one row, then use a table variable
instead.
AMB
"joseph.fanelli@.vba.va.gov" wrote:
> I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>|||If you are only populating with one row then chances are you can do this
without a temp table. But to answer your question no others can not see
this. But you might want to do as Alejandro says and use a table variable
instead.
Andrew J. Kelly SQL MVP
<joseph.fanelli@.vba.va.gov> wrote in message
news:1113844980.325249.265010@.l41g2000cwc.googlegroups.com...
>I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>|||Why even use a temporary table?
Declare variables, populate them, then return a recorset:
select @.variable1 as ..., @.variable2 as ... @.variable3 as ... etc.
<joseph.fanelli@.vba.va.gov> wrote in message
news:1113844980.325249.265010@.l41g2000cwc.googlegroups.com...
>I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>|||Andrew,
I did not think about it, but yes, better to use an output parameter. What
about a connection taken from the pool, if the sp does not drop the temporar
y
table explicitly, and uses this code to create it:
if object_id('tempdb..#temptbl') is null
create table #temptbl ...
...
then next time the sp is executed using the same connection, a row inserted
by previous execution can be selected, correct?
AMB
"Andrew J. Kelly" wrote:
> If you are only populating with one row then chances are you can do this
> without a temp table. But to answer your question no others can not see
> this. But you might want to do as Alejandro says and use a table variable
> instead.
> --
> Andrew J. Kelly SQL MVP
>
> <joseph.fanelli@.vba.va.gov> wrote in message
> news:1113844980.325249.265010@.l41g2000cwc.googlegroups.com...
>
>|||If they are using connection pooling and follow the proper procedures a
sp_resetconnection is called that will clean up any such things and put the
connection settings back to the proper settings. Normally a temp table
created in a sp will go out of scope when the sp is completed as well. It
is only if they created the temp table outside of a sp that it will hang
around.
Andrew J. Kelly SQL MVP
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:8C7B0F8B-12B7-49F0-818B-F39C2415C8FE@.microsoft.com...
> Andrew,
> I did not think about it, but yes, better to use an output parameter. What
> about a connection taken from the pool, if the sp does not drop the
> temporary
> table explicitly, and uses this code to create it:
> if object_id('tempdb..#temptbl') is null
> create table #temptbl ...
> ...
> then next time the sp is executed using the same connection, a row
> inserted
> by previous execution can be selected, correct?
>
> AMB
> "Andrew J. Kelly" wrote:
>|||Andrew,
You are right, the temporary table goes out of scope when the sp has
finished. I wonder what kind of cleaning is done by sp_resetconnection, I ca
n
not find anything about it in the BOL.
Thanks,
AMB
"Andrew J. Kelly" wrote:
> If they are using connection pooling and follow the proper procedures a
> sp_resetconnection is called that will clean up any such things and put th
e
> connection settings back to the proper settings. Normally a temp table
> created in a sp will go out of scope when the sp is completed as well. It
> is only if they created the temp table outside of a sp that it will hang
> around.
> --
> Andrew J. Kelly SQL MVP
>
> "Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in messag
e
> news:8C7B0F8B-12B7-49F0-818B-F39C2415C8FE@.microsoft.com...
>
>
question on temporary tables
I have a stored procedure that creates a temporary table, populates it
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
Joe
The #tablename temp table exists only for the connection that calls the
proc. You are safe to call the same proc and the same table name as many
times as necessary without fear. Do not however use ##{tablename}. This will
cause a global temp table to be created and is referenceable by other
connections until the connection that created it is dropped.
--Rick Butler
"joseph.fanelli@.vba.va.gov" wrote:
> I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>
|||Why not just select that one row and avoid creating a temp table? Improper
use of temporary objects in stored procedures can cause recompiles and
affect SQL performance. See
http://support.microsoft.com/default...b;en-us;243586 for details.
Adrian
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:BC656DA7-7BB2-4527-94D5-BCD53D702DE4@.microsoft.com...[vbcol=seagreen]
> The #tablename temp table exists only for the connection that calls the
> proc. You are safe to call the same proc and the same table name as many
> times as necessary without fear. Do not however use ##{tablename}. This
> will
> cause a global temp table to be created and is referenceable by other
> connections until the connection that created it is dropped.
> --Rick Butler
> "joseph.fanelli@.vba.va.gov" wrote:
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
Joe
The #tablename temp table exists only for the connection that calls the
proc. You are safe to call the same proc and the same table name as many
times as necessary without fear. Do not however use ##{tablename}. This will
cause a global temp table to be created and is referenceable by other
connections until the connection that created it is dropped.
--Rick Butler
"joseph.fanelli@.vba.va.gov" wrote:
> I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>
|||Why not just select that one row and avoid creating a temp table? Improper
use of temporary objects in stored procedures can cause recompiles and
affect SQL performance. See
http://support.microsoft.com/default...b;en-us;243586 for details.
Adrian
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:BC656DA7-7BB2-4527-94D5-BCD53D702DE4@.microsoft.com...[vbcol=seagreen]
> The #tablename temp table exists only for the connection that calls the
> proc. You are safe to call the same proc and the same table name as many
> times as necessary without fear. Do not however use ##{tablename}. This
> will
> cause a global temp table to be created and is referenceable by other
> connections until the connection that created it is dropped.
> --Rick Butler
> "joseph.fanelli@.vba.va.gov" wrote:
question on temporary tables
I have a stored procedure that creates a temporary table, populates it
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
Joe
Connections are always separate from each other, regardless of whether the
client connects using the same login information or not. Your temporary
tables will not collide or be visible to other connections.
Geoff N. Hiten
Microsoft SQL Server MVP
<joseph.fanelli@.vba.va.gov> wrote in message
news:1113844860.949837.190280@.z14g2000cwz.googlegr oups.com...
>I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>
sql
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
Joe
Connections are always separate from each other, regardless of whether the
client connects using the same login information or not. Your temporary
tables will not collide or be visible to other connections.
Geoff N. Hiten
Microsoft SQL Server MVP
<joseph.fanelli@.vba.va.gov> wrote in message
news:1113844860.949837.190280@.z14g2000cwz.googlegr oups.com...
>I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>
sql
question on temporary tables
I have a stored procedure that creates a temporary table, populates it
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
JoeConnections are always separate from each other, regardless of whether the
client connects using the same login information or not. Your temporary
tables will not collide or be visible to other connections.
Geoff N. Hiten
Microsoft SQL Server MVP
<joseph.fanelli@.vba.va.gov> wrote in message
news:1113844860.949837.190280@.z14g2000cwz.googlegroups.com...
>I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
JoeConnections are always separate from each other, regardless of whether the
client connects using the same login information or not. Your temporary
tables will not collide or be visible to other connections.
Geoff N. Hiten
Microsoft SQL Server MVP
<joseph.fanelli@.vba.va.gov> wrote in message
news:1113844860.949837.190280@.z14g2000cwz.googlegroups.com...
>I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>
question on temporary tables
I have a stored procedure that creates a temporary table, populates it
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
JoeThe #tablename temp table exists only for the connection that calls the
proc. You are safe to call the same proc and the same table name as many
times as necessary without fear. Do not however use ##{tablename}. This will
cause a global temp table to be created and is referenceable by other
connections until the connection that created it is dropped.
--Rick Butler
"joseph.fanelli@.vba.va.gov" wrote:
> I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>|||Why not just select that one row and avoid creating a temp table? Improper
use of temporary objects in stored procedures can cause recompiles and
affect SQL performance. See
http://support.microsoft.com/default.aspx?scid=kb;en-us;243586 for details.
Adrian
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:BC656DA7-7BB2-4527-94D5-BCD53D702DE4@.microsoft.com...
> The #tablename temp table exists only for the connection that calls the
> proc. You are safe to call the same proc and the same table name as many
> times as necessary without fear. Do not however use ##{tablename}. This
> will
> cause a global temp table to be created and is referenceable by other
> connections until the connection that created it is dropped.
> --Rick Butler
> "joseph.fanelli@.vba.va.gov" wrote:
>> I have a stored procedure that creates a temporary table, populates it
>> with one record, and then returns that record to an ASP. I've read
>> that by prefixing the the tablename with a #, that only the connection
>> that created it can access it.
>> An IIS server will be making the connection and uses the same
>> connection string for all users. Even though the connection string is
>> the same, and the temporary table name is the same, will the temporary
>> table created only be available to the specific connection that created
>> it? I'm concerned that if multiple users make a request to that stored
>> procedure, they may get someone else's data.
>> thanks,
>> Joe
>>
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
JoeThe #tablename temp table exists only for the connection that calls the
proc. You are safe to call the same proc and the same table name as many
times as necessary without fear. Do not however use ##{tablename}. This will
cause a global temp table to be created and is referenceable by other
connections until the connection that created it is dropped.
--Rick Butler
"joseph.fanelli@.vba.va.gov" wrote:
> I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>|||Why not just select that one row and avoid creating a temp table? Improper
use of temporary objects in stored procedures can cause recompiles and
affect SQL performance. See
http://support.microsoft.com/default.aspx?scid=kb;en-us;243586 for details.
Adrian
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:BC656DA7-7BB2-4527-94D5-BCD53D702DE4@.microsoft.com...
> The #tablename temp table exists only for the connection that calls the
> proc. You are safe to call the same proc and the same table name as many
> times as necessary without fear. Do not however use ##{tablename}. This
> will
> cause a global temp table to be created and is referenceable by other
> connections until the connection that created it is dropped.
> --Rick Butler
> "joseph.fanelli@.vba.va.gov" wrote:
>> I have a stored procedure that creates a temporary table, populates it
>> with one record, and then returns that record to an ASP. I've read
>> that by prefixing the the tablename with a #, that only the connection
>> that created it can access it.
>> An IIS server will be making the connection and uses the same
>> connection string for all users. Even though the connection string is
>> the same, and the temporary table name is the same, will the temporary
>> table created only be available to the specific connection that created
>> it? I'm concerned that if multiple users make a request to that stored
>> procedure, they may get someone else's data.
>> thanks,
>> Joe
>>
question on temporary tables
I have a stored procedure that creates a temporary table, populates it
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
JoeThe #tablename temp table exists only for the connection that calls the
proc. You are safe to call the same proc and the same table name as many
times as necessary without fear. Do not however use ##{tablename}. This
will
cause a global temp table to be created and is referenceable by other
connections until the connection that created it is dropped.
--Rick Butler
"joseph.fanelli@.vba.va.gov" wrote:
> I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>|||Why not just select that one row and avoid creating a temp table? Improper
use of temporary objects in stored procedures can cause recompiles and
affect SQL performance. See
http://support.microsoft.com/defaul...kb;en-us;243586 for details.
Adrian
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:BC656DA7-7BB2-4527-94D5-BCD53D702DE4@.microsoft.com...[vbcol=seagreen]
> The #tablename temp table exists only for the connection that calls the
> proc. You are safe to call the same proc and the same table name as many
> times as necessary without fear. Do not however use ##{tablename}. Th
is
> will
> cause a global temp table to be created and is referenceable by other
> connections until the connection that created it is dropped.
> --Rick Butler
> "joseph.fanelli@.vba.va.gov" wrote:
>
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
JoeThe #tablename temp table exists only for the connection that calls the
proc. You are safe to call the same proc and the same table name as many
times as necessary without fear. Do not however use ##{tablename}. This
will
cause a global temp table to be created and is referenceable by other
connections until the connection that created it is dropped.
--Rick Butler
"joseph.fanelli@.vba.va.gov" wrote:
> I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>|||Why not just select that one row and avoid creating a temp table? Improper
use of temporary objects in stored procedures can cause recompiles and
affect SQL performance. See
http://support.microsoft.com/defaul...kb;en-us;243586 for details.
Adrian
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:BC656DA7-7BB2-4527-94D5-BCD53D702DE4@.microsoft.com...[vbcol=seagreen]
> The #tablename temp table exists only for the connection that calls the
> proc. You are safe to call the same proc and the same table name as many
> times as necessary without fear. Do not however use ##{tablename}. Th
is
> will
> cause a global temp table to be created and is referenceable by other
> connections until the connection that created it is dropped.
> --Rick Butler
> "joseph.fanelli@.vba.va.gov" wrote:
>
question on temporary tables
I have a stored procedure that creates a temporary table, populates it
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
JoeConnections are always separate from each other, regardless of whether the
client connects using the same login information or not. Your temporary
tables will not collide or be visible to other connections.
Geoff N. Hiten
Microsoft SQL Server MVP
<joseph.fanelli@.vba.va.gov> wrote in message
news:1113844860.949837.190280@.z14g2000cwz.googlegroups.com...
>I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>
with one record, and then returns that record to an ASP. I've read
that by prefixing the the tablename with a #, that only the connection
that created it can access it.
An IIS server will be making the connection and uses the same
connection string for all users. Even though the connection string is
the same, and the temporary table name is the same, will the temporary
table created only be available to the specific connection that created
it? I'm concerned that if multiple users make a request to that stored
procedure, they may get someone else's data.
thanks,
JoeConnections are always separate from each other, regardless of whether the
client connects using the same login information or not. Your temporary
tables will not collide or be visible to other connections.
Geoff N. Hiten
Microsoft SQL Server MVP
<joseph.fanelli@.vba.va.gov> wrote in message
news:1113844860.949837.190280@.z14g2000cwz.googlegroups.com...
>I have a stored procedure that creates a temporary table, populates it
> with one record, and then returns that record to an ASP. I've read
> that by prefixing the the tablename with a #, that only the connection
> that created it can access it.
> An IIS server will be making the connection and uses the same
> connection string for all users. Even though the connection string is
> the same, and the temporary table name is the same, will the temporary
> table created only be available to the specific connection that created
> it? I'm concerned that if multiple users make a request to that stored
> procedure, they may get someone else's data.
> thanks,
> Joe
>
Question on subreports
Right now we have one report with two tables in it. The tables are
populated from two different stored procedures. The two tables contain
detail and summary information respectively.
We call the report from a web app, and users can elect to see detail,
summary, or both.
We pass a parameter to control this, and set the tables visiblity
based on it.
Now, I just realized that each of the stored procedures is going to
execute, even if one or the reports is not visible, and I wondered if I
could set this up so I could keep a procedure from executing if we
weren't going to use it.
I wondered if I could do this by using subreports, and including them
based on a parameter.
I thought I'd ask before I started in on this to see if anybody has
done this already.
TIA,
JimMy understanding is when a table or any other data region item is hidden the
underlying dataset is not executed.
You can try to check it by running the SQL Server Profiler Tool.
Med Bouchenafa
<jhcorey@.yahoo.com> a écrit dans le message de news:
1138307871.859110.33690@.z14g2000cwz.googlegroups.com...
> Right now we have one report with two tables in it. The tables are
> populated from two different stored procedures. The two tables contain
> detail and summary information respectively.
> We call the report from a web app, and users can elect to see detail,
> summary, or both.
> We pass a parameter to control this, and set the tables visiblity
> based on it.
> Now, I just realized that each of the stored procedures is going to
> execute, even if one or the reports is not visible, and I wondered if I
> could set this up so I could keep a procedure from executing if we
> weren't going to use it.
> I wondered if I could do this by using subreports, and including them
> based on a parameter.
> I thought I'd ask before I started in on this to see if anybody has
> done this already.
> TIA,
> Jim
>|||In our situation the procedure it's easy to see because one of the
procedures throws an error depending on the data we pass it. There is
a table that uses the dataset from this procedure, and if we set the
table's visibility property to false based on a report parameter, we
still see the error and the reference to the procedure.
It may be that there is somewhere else the procedure is referenced, so
I'll look some more before changing everything.
populated from two different stored procedures. The two tables contain
detail and summary information respectively.
We call the report from a web app, and users can elect to see detail,
summary, or both.
We pass a parameter to control this, and set the tables visiblity
based on it.
Now, I just realized that each of the stored procedures is going to
execute, even if one or the reports is not visible, and I wondered if I
could set this up so I could keep a procedure from executing if we
weren't going to use it.
I wondered if I could do this by using subreports, and including them
based on a parameter.
I thought I'd ask before I started in on this to see if anybody has
done this already.
TIA,
JimMy understanding is when a table or any other data region item is hidden the
underlying dataset is not executed.
You can try to check it by running the SQL Server Profiler Tool.
Med Bouchenafa
<jhcorey@.yahoo.com> a écrit dans le message de news:
1138307871.859110.33690@.z14g2000cwz.googlegroups.com...
> Right now we have one report with two tables in it. The tables are
> populated from two different stored procedures. The two tables contain
> detail and summary information respectively.
> We call the report from a web app, and users can elect to see detail,
> summary, or both.
> We pass a parameter to control this, and set the tables visiblity
> based on it.
> Now, I just realized that each of the stored procedures is going to
> execute, even if one or the reports is not visible, and I wondered if I
> could set this up so I could keep a procedure from executing if we
> weren't going to use it.
> I wondered if I could do this by using subreports, and including them
> based on a parameter.
> I thought I'd ask before I started in on this to see if anybody has
> done this already.
> TIA,
> Jim
>|||In our situation the procedure it's easy to see because one of the
procedures throws an error depending on the data we pass it. There is
a table that uses the dataset from this procedure, and if we set the
table's visibility property to false based on a report parameter, we
still see the error and the reference to the procedure.
It may be that there is somewhere else the procedure is referenced, so
I'll look some more before changing everything.
Wednesday, March 21, 2012
Question on SQL tables
Hi everyone,
I′m starting using SQL 2005 on visual studio 2005, and I have a question:
I have a table named employees in which I have 2 columns, one named "last used" which has the smalldatetime data type and the other named "salary" which has the decimal data type.
Now, I want to use a Select statement, to display in a new table 2 new columns, one with the sum of the salaries that correspond to the current month and the other with the sum of the values that belong to the previous month. I mean by this, all the salaries from july should be added up and be displayed in one column and all the ones from june should be added and displayed in the other column.
Can someone help me please?
Thanks in advance
Using this data set
..and this query
select
sum(case month(lastused) when month(getdate()) then salary end) as CurrentMonthSalary
,sum(case month(lastused) when month(getdate()) -1 then salary end) as PrevMonthSalary
from dbo.salary
...I return these results
I believe that's what you are looking for.
Tim
Question on SQL Server SQL
In DB2 one can issue a query like
db2 -x 'select tabname from syscat.tables'
and the output is cleaned up so all you get is/are the requested table
name(s)...no dotted lines...no column headings.
Does SQL Server have a similar construct?
Thanks
Gerryno dotted lines...no column headings.???
Check out the information_schema views in bol. Otherwise check out system tables also in bol. Without the version of SS you are using I can't be more specific.|||I think what you are looking for is bcp.exe
it's a console app for exporting data from SQL Server to a flat file.|||I think what you are looking for is bcp.exeAh! Now I get it.|||specifically:
bcp "select name from mydatabase.dbo.sysobjects where xtype='U'" queryout file.txt -c -T -SSERVERNAME|||Sorry about not posting the version.
Its SQL Server 2005.
Ok so it seems that SQL Server SQL does not have the -x construct and that the bcp.exe is needed.
Thanks
db2 -x 'select tabname from syscat.tables'
and the output is cleaned up so all you get is/are the requested table
name(s)...no dotted lines...no column headings.
Does SQL Server have a similar construct?
Thanks
Gerryno dotted lines...no column headings.???
Check out the information_schema views in bol. Otherwise check out system tables also in bol. Without the version of SS you are using I can't be more specific.|||I think what you are looking for is bcp.exe
it's a console app for exporting data from SQL Server to a flat file.|||I think what you are looking for is bcp.exeAh! Now I get it.|||specifically:
bcp "select name from mydatabase.dbo.sysobjects where xtype='U'" queryout file.txt -c -T -SSERVERNAME|||Sorry about not posting the version.
Its SQL Server 2005.
Ok so it seems that SQL Server SQL does not have the -x construct and that the bcp.exe is needed.
Thanks
Tuesday, March 20, 2012
Question on security
Scenario: We have an Sql Server system and want to set up a payroll system.
We have about 30 tables in this database. We are now going to be handling
outside companies payroll information.
Setup 1: One of the fields in the tables would be a company code. This
would logically separate company A's data from company B's data.
Our question is on security. How secure is the data if it is all in one
database? If someone were to hack the database, they could potentially have
access to every companies data.
Setup 2: One way around that would be to replicate the 30 tables for each
company we bring on board. If we were to have 100 companies, we would have
100 databases and 300 tables.
This, of course, would be a problem as we make changes to the tables, since
we would have to make the changes to the same tables in each of the 100
databases.
One benefit to this setup is that if someone were to hack one database, they
wouldn't necessarilly have access to other companies data since they would
be in other database, even though all the databases reside on the same
machine under the same Sql Server.
This brings up the issue of multiple machines - which would really be going
overboard.
I am just trying to use due diligence here to see what my possible problems
are and whether we could be over thinking the problem.
Payroll data is very sensitive and we need to make sure we are going far
enough to protect it, but not too far to make it unwieldy.
The other question would be whether maybe having all the data in one
database might slow down the response too much where if we had separate
databases, searches and updates might be faster.
Just looking for ideas from others who may have wrestled with these
questions.
Thanks,
Tom.
On Wed, 1 Dec 2004 15:57:48 -0800, "tshad"
<tscheiderich@.ftsolutions.com> wrote:
>Just looking for ideas from others who may have wrestled with these
>questions.
Old questions, everyone chooses their own answers.
You can partition tables and use views to restrict users to their own
company's rows and stuff like that, if you want to keep things in a
single database and/or single tables.
There are always tradeoffs between convenience, performance, and
security. What's the old cliche, "good, fast, cheap - choose two".
J.
|||> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
>
No, don't use separate databases. Nowadays you can have a very big database
and if you properly designed it you will not have any problem in terms of
perfomance. You probably would not want to maintain many databases all
system calagos and...
If you defined indexes on the tables and do provide tuning the database
searches and updates might be faster so it has not to do with having many
databases.
Also, I'd remove a guest account and make sure that all may users have
appropriate permissions to access the tables.
Don't GRANT them access to underlying tables instead create views to select
data.
Visit on this web site to read more about security of the database
http://vyaskn.tripod.com/sql_server_..._practices.htm
http://vyaskn.tripod.com/row_level_s..._databases.htm
"tshad" <tscheiderich@.ftsolutions.com> wrote in message
news:OgCxbGA2EHA.2112@.TK2MSFTNGP15.phx.gbl...
> Scenario: We have an Sql Server system and want to set up a payroll
system.
> We have about 30 tables in this database. We are now going to be handling
> outside companies payroll information.
> Setup 1: One of the fields in the tables would be a company code. This
> would logically separate company A's data from company B's data.
> Our question is on security. How secure is the data if it is all in one
> database? If someone were to hack the database, they could potentially
have
> access to every companies data.
> Setup 2: One way around that would be to replicate the 30 tables for each
> company we bring on board. If we were to have 100 companies, we would
have
> 100 databases and 300 tables.
> This, of course, would be a problem as we make changes to the tables,
since
> we would have to make the changes to the same tables in each of the 100
> databases.
> One benefit to this setup is that if someone were to hack one database,
they
> wouldn't necessarilly have access to other companies data since they would
> be in other database, even though all the databases reside on the same
> machine under the same Sql Server.
> This brings up the issue of multiple machines - which would really be
going
> overboard.
> I am just trying to use due diligence here to see what my possible
problems
> are and whether we could be over thinking the problem.
> Payroll data is very sensitive and we need to make sure we are going far
> enough to protect it, but not too far to make it unwieldy.
> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
> Just looking for ideas from others who may have wrestled with these
> questions.
> Thanks,
> Tom.
>
We have about 30 tables in this database. We are now going to be handling
outside companies payroll information.
Setup 1: One of the fields in the tables would be a company code. This
would logically separate company A's data from company B's data.
Our question is on security. How secure is the data if it is all in one
database? If someone were to hack the database, they could potentially have
access to every companies data.
Setup 2: One way around that would be to replicate the 30 tables for each
company we bring on board. If we were to have 100 companies, we would have
100 databases and 300 tables.
This, of course, would be a problem as we make changes to the tables, since
we would have to make the changes to the same tables in each of the 100
databases.
One benefit to this setup is that if someone were to hack one database, they
wouldn't necessarilly have access to other companies data since they would
be in other database, even though all the databases reside on the same
machine under the same Sql Server.
This brings up the issue of multiple machines - which would really be going
overboard.
I am just trying to use due diligence here to see what my possible problems
are and whether we could be over thinking the problem.
Payroll data is very sensitive and we need to make sure we are going far
enough to protect it, but not too far to make it unwieldy.
The other question would be whether maybe having all the data in one
database might slow down the response too much where if we had separate
databases, searches and updates might be faster.
Just looking for ideas from others who may have wrestled with these
questions.
Thanks,
Tom.
On Wed, 1 Dec 2004 15:57:48 -0800, "tshad"
<tscheiderich@.ftsolutions.com> wrote:
>Just looking for ideas from others who may have wrestled with these
>questions.
Old questions, everyone chooses their own answers.
You can partition tables and use views to restrict users to their own
company's rows and stuff like that, if you want to keep things in a
single database and/or single tables.
There are always tradeoffs between convenience, performance, and
security. What's the old cliche, "good, fast, cheap - choose two".
J.
|||> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
>
No, don't use separate databases. Nowadays you can have a very big database
and if you properly designed it you will not have any problem in terms of
perfomance. You probably would not want to maintain many databases all
system calagos and...
If you defined indexes on the tables and do provide tuning the database
searches and updates might be faster so it has not to do with having many
databases.
Also, I'd remove a guest account and make sure that all may users have
appropriate permissions to access the tables.
Don't GRANT them access to underlying tables instead create views to select
data.
Visit on this web site to read more about security of the database
http://vyaskn.tripod.com/sql_server_..._practices.htm
http://vyaskn.tripod.com/row_level_s..._databases.htm
"tshad" <tscheiderich@.ftsolutions.com> wrote in message
news:OgCxbGA2EHA.2112@.TK2MSFTNGP15.phx.gbl...
> Scenario: We have an Sql Server system and want to set up a payroll
system.
> We have about 30 tables in this database. We are now going to be handling
> outside companies payroll information.
> Setup 1: One of the fields in the tables would be a company code. This
> would logically separate company A's data from company B's data.
> Our question is on security. How secure is the data if it is all in one
> database? If someone were to hack the database, they could potentially
have
> access to every companies data.
> Setup 2: One way around that would be to replicate the 30 tables for each
> company we bring on board. If we were to have 100 companies, we would
have
> 100 databases and 300 tables.
> This, of course, would be a problem as we make changes to the tables,
since
> we would have to make the changes to the same tables in each of the 100
> databases.
> One benefit to this setup is that if someone were to hack one database,
they
> wouldn't necessarilly have access to other companies data since they would
> be in other database, even though all the databases reside on the same
> machine under the same Sql Server.
> This brings up the issue of multiple machines - which would really be
going
> overboard.
> I am just trying to use due diligence here to see what my possible
problems
> are and whether we could be over thinking the problem.
> Payroll data is very sensitive and we need to make sure we are going far
> enough to protect it, but not too far to make it unwieldy.
> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
> Just looking for ideas from others who may have wrestled with these
> questions.
> Thanks,
> Tom.
>
Question on security
Scenario: We have an Sql Server system and want to set up a payroll system.
We have about 30 tables in this database. We are now going to be handling
outside companies payroll information.
Setup 1: One of the fields in the tables would be a company code. This
would logically separate company A's data from company B's data.
Our question is on security. How secure is the data if it is all in one
database? If someone were to hack the database, they could potentially have
access to every companies data.
Setup 2: One way around that would be to replicate the 30 tables for each
company we bring on board. If we were to have 100 companies, we would have
100 databases and 300 tables.
This, of course, would be a problem as we make changes to the tables, since
we would have to make the changes to the same tables in each of the 100
databases.
One benefit to this setup is that if someone were to hack one database, they
wouldn't necessarilly have access to other companies data since they would
be in other database, even though all the databases reside on the same
machine under the same Sql Server.
This brings up the issue of multiple machines - which would really be going
overboard.
I am just trying to use due diligence here to see what my possible problems
are and whether we could be over thinking the problem.
Payroll data is very sensitive and we need to make sure we are going far
enough to protect it, but not too far to make it unwieldy.
The other question would be whether maybe having all the data in one
database might slow down the response too much where if we had separate
databases, searches and updates might be faster.
Just looking for ideas from others who may have wrestled with these
questions.
Thanks,
Tom.On Wed, 1 Dec 2004 15:57:48 -0800, "tshad"
<tscheiderich@.ftsolutions.com> wrote:
>Just looking for ideas from others who may have wrestled with these
>questions.
Old questions, everyone chooses their own answers.
You can partition tables and use views to restrict users to their own
company's rows and stuff like that, if you want to keep things in a
single database and/or single tables.
There are always tradeoffs between convenience, performance, and
security. What's the old cliche, "good, fast, cheap - choose two".
J.|||> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
>
No, don't use separate databases. Nowadays you can have a very big database
and if you properly designed it you will not have any problem in terms of
perfomance. You probably would not want to maintain many databases all
system calagos and...
If you defined indexes on the tables and do provide tuning the database
searches and updates might be faster so it has not to do with having many
databases.
Also, I'd remove a guest account and make sure that all may users have
appropriate permissions to access the tables.
Don't GRANT them access to underlying tables instead create views to select
data.
Visit on this web site to read more about security of the database
http://vyaskn.tripod.com/sql_server...t_practices.htm
http://vyaskn.tripod.com/ row_level...as
es.htm
"tshad" <tscheiderich@.ftsolutions.com> wrote in message
news:OgCxbGA2EHA.2112@.TK2MSFTNGP15.phx.gbl...
> Scenario: We have an Sql Server system and want to set up a payroll
system.
> We have about 30 tables in this database. We are now going to be handling
> outside companies payroll information.
> Setup 1: One of the fields in the tables would be a company code. This
> would logically separate company A's data from company B's data.
> Our question is on security. How secure is the data if it is all in one
> database? If someone were to hack the database, they could potentially
have
> access to every companies data.
> Setup 2: One way around that would be to replicate the 30 tables for each
> company we bring on board. If we were to have 100 companies, we would
have
> 100 databases and 300 tables.
> This, of course, would be a problem as we make changes to the tables,
since
> we would have to make the changes to the same tables in each of the 100
> databases.
> One benefit to this setup is that if someone were to hack one database,
they
> wouldn't necessarilly have access to other companies data since they would
> be in other database, even though all the databases reside on the same
> machine under the same Sql Server.
> This brings up the issue of multiple machines - which would really be
going
> overboard.
> I am just trying to use due diligence here to see what my possible
problems
> are and whether we could be over thinking the problem.
> Payroll data is very sensitive and we need to make sure we are going far
> enough to protect it, but not too far to make it unwieldy.
> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
> Just looking for ideas from others who may have wrestled with these
> questions.
> Thanks,
> Tom.
>
We have about 30 tables in this database. We are now going to be handling
outside companies payroll information.
Setup 1: One of the fields in the tables would be a company code. This
would logically separate company A's data from company B's data.
Our question is on security. How secure is the data if it is all in one
database? If someone were to hack the database, they could potentially have
access to every companies data.
Setup 2: One way around that would be to replicate the 30 tables for each
company we bring on board. If we were to have 100 companies, we would have
100 databases and 300 tables.
This, of course, would be a problem as we make changes to the tables, since
we would have to make the changes to the same tables in each of the 100
databases.
One benefit to this setup is that if someone were to hack one database, they
wouldn't necessarilly have access to other companies data since they would
be in other database, even though all the databases reside on the same
machine under the same Sql Server.
This brings up the issue of multiple machines - which would really be going
overboard.
I am just trying to use due diligence here to see what my possible problems
are and whether we could be over thinking the problem.
Payroll data is very sensitive and we need to make sure we are going far
enough to protect it, but not too far to make it unwieldy.
The other question would be whether maybe having all the data in one
database might slow down the response too much where if we had separate
databases, searches and updates might be faster.
Just looking for ideas from others who may have wrestled with these
questions.
Thanks,
Tom.On Wed, 1 Dec 2004 15:57:48 -0800, "tshad"
<tscheiderich@.ftsolutions.com> wrote:
>Just looking for ideas from others who may have wrestled with these
>questions.
Old questions, everyone chooses their own answers.
You can partition tables and use views to restrict users to their own
company's rows and stuff like that, if you want to keep things in a
single database and/or single tables.
There are always tradeoffs between convenience, performance, and
security. What's the old cliche, "good, fast, cheap - choose two".
J.|||> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
>
No, don't use separate databases. Nowadays you can have a very big database
and if you properly designed it you will not have any problem in terms of
perfomance. You probably would not want to maintain many databases all
system calagos and...
If you defined indexes on the tables and do provide tuning the database
searches and updates might be faster so it has not to do with having many
databases.
Also, I'd remove a guest account and make sure that all may users have
appropriate permissions to access the tables.
Don't GRANT them access to underlying tables instead create views to select
data.
Visit on this web site to read more about security of the database
http://vyaskn.tripod.com/sql_server...t_practices.htm
http://vyaskn.tripod.com/ row_level...as
es.htm
"tshad" <tscheiderich@.ftsolutions.com> wrote in message
news:OgCxbGA2EHA.2112@.TK2MSFTNGP15.phx.gbl...
> Scenario: We have an Sql Server system and want to set up a payroll
system.
> We have about 30 tables in this database. We are now going to be handling
> outside companies payroll information.
> Setup 1: One of the fields in the tables would be a company code. This
> would logically separate company A's data from company B's data.
> Our question is on security. How secure is the data if it is all in one
> database? If someone were to hack the database, they could potentially
have
> access to every companies data.
> Setup 2: One way around that would be to replicate the 30 tables for each
> company we bring on board. If we were to have 100 companies, we would
have
> 100 databases and 300 tables.
> This, of course, would be a problem as we make changes to the tables,
since
> we would have to make the changes to the same tables in each of the 100
> databases.
> One benefit to this setup is that if someone were to hack one database,
they
> wouldn't necessarilly have access to other companies data since they would
> be in other database, even though all the databases reside on the same
> machine under the same Sql Server.
> This brings up the issue of multiple machines - which would really be
going
> overboard.
> I am just trying to use due diligence here to see what my possible
problems
> are and whether we could be over thinking the problem.
> Payroll data is very sensitive and we need to make sure we are going far
> enough to protect it, but not too far to make it unwieldy.
> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
> Just looking for ideas from others who may have wrestled with these
> questions.
> Thanks,
> Tom.
>
Question on security
Scenario: We have an Sql Server system and want to set up a payroll system.
We have about 30 tables in this database. We are now going to be handling
outside companies payroll information.
Setup 1: One of the fields in the tables would be a company code. This
would logically separate company A's data from company B's data.
Our question is on security. How secure is the data if it is all in one
database? If someone were to hack the database, they could potentially have
access to every companies data.
Setup 2: One way around that would be to replicate the 30 tables for each
company we bring on board. If we were to have 100 companies, we would have
100 databases and 300 tables.
This, of course, would be a problem as we make changes to the tables, since
we would have to make the changes to the same tables in each of the 100
databases.
One benefit to this setup is that if someone were to hack one database, they
wouldn't necessarilly have access to other companies data since they would
be in other database, even though all the databases reside on the same
machine under the same Sql Server.
This brings up the issue of multiple machines - which would really be going
overboard.
I am just trying to use due diligence here to see what my possible problems
are and whether we could be over thinking the problem.
Payroll data is very sensitive and we need to make sure we are going far
enough to protect it, but not too far to make it unwieldy.
The other question would be whether maybe having all the data in one
database might slow down the response too much where if we had separate
databases, searches and updates might be faster.
Just looking for ideas from others who may have wrestled with these
questions.
Thanks,
Tom.On Wed, 1 Dec 2004 15:57:48 -0800, "tshad"
<tscheiderich@.ftsolutions.com> wrote:
>Just looking for ideas from others who may have wrestled with these
>questions.
Old questions, everyone chooses their own answers.
You can partition tables and use views to restrict users to their own
company's rows and stuff like that, if you want to keep things in a
single database and/or single tables.
There are always tradeoffs between convenience, performance, and
security. What's the old cliche, "good, fast, cheap - choose two".
J.|||> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
>
No, don't use separate databases. Nowadays you can have a very big database
and if you properly designed it you will not have any problem in terms of
perfomance. You probably would not want to maintain many databases all
system calagos and...
If you defined indexes on the tables and do provide tuning the database
searches and updates might be faster so it has not to do with having many
databases.
Also, I'd remove a guest account and make sure that all may users have
appropriate permissions to access the tables.
Don't GRANT them access to underlying tables instead create views to select
data.
Visit on this web site to read more about security of the database
http://vyaskn.tripod.com/sql_server_security_best_practices.htm
http://vyaskn.tripod.com/row_level_security_in_sql_server_databases.htm
"tshad" <tscheiderich@.ftsolutions.com> wrote in message
news:OgCxbGA2EHA.2112@.TK2MSFTNGP15.phx.gbl...
> Scenario: We have an Sql Server system and want to set up a payroll
system.
> We have about 30 tables in this database. We are now going to be handling
> outside companies payroll information.
> Setup 1: One of the fields in the tables would be a company code. This
> would logically separate company A's data from company B's data.
> Our question is on security. How secure is the data if it is all in one
> database? If someone were to hack the database, they could potentially
have
> access to every companies data.
> Setup 2: One way around that would be to replicate the 30 tables for each
> company we bring on board. If we were to have 100 companies, we would
have
> 100 databases and 300 tables.
> This, of course, would be a problem as we make changes to the tables,
since
> we would have to make the changes to the same tables in each of the 100
> databases.
> One benefit to this setup is that if someone were to hack one database,
they
> wouldn't necessarilly have access to other companies data since they would
> be in other database, even though all the databases reside on the same
> machine under the same Sql Server.
> This brings up the issue of multiple machines - which would really be
going
> overboard.
> I am just trying to use due diligence here to see what my possible
problems
> are and whether we could be over thinking the problem.
> Payroll data is very sensitive and we need to make sure we are going far
> enough to protect it, but not too far to make it unwieldy.
> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
> Just looking for ideas from others who may have wrestled with these
> questions.
> Thanks,
> Tom.
>
We have about 30 tables in this database. We are now going to be handling
outside companies payroll information.
Setup 1: One of the fields in the tables would be a company code. This
would logically separate company A's data from company B's data.
Our question is on security. How secure is the data if it is all in one
database? If someone were to hack the database, they could potentially have
access to every companies data.
Setup 2: One way around that would be to replicate the 30 tables for each
company we bring on board. If we were to have 100 companies, we would have
100 databases and 300 tables.
This, of course, would be a problem as we make changes to the tables, since
we would have to make the changes to the same tables in each of the 100
databases.
One benefit to this setup is that if someone were to hack one database, they
wouldn't necessarilly have access to other companies data since they would
be in other database, even though all the databases reside on the same
machine under the same Sql Server.
This brings up the issue of multiple machines - which would really be going
overboard.
I am just trying to use due diligence here to see what my possible problems
are and whether we could be over thinking the problem.
Payroll data is very sensitive and we need to make sure we are going far
enough to protect it, but not too far to make it unwieldy.
The other question would be whether maybe having all the data in one
database might slow down the response too much where if we had separate
databases, searches and updates might be faster.
Just looking for ideas from others who may have wrestled with these
questions.
Thanks,
Tom.On Wed, 1 Dec 2004 15:57:48 -0800, "tshad"
<tscheiderich@.ftsolutions.com> wrote:
>Just looking for ideas from others who may have wrestled with these
>questions.
Old questions, everyone chooses their own answers.
You can partition tables and use views to restrict users to their own
company's rows and stuff like that, if you want to keep things in a
single database and/or single tables.
There are always tradeoffs between convenience, performance, and
security. What's the old cliche, "good, fast, cheap - choose two".
J.|||> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
>
No, don't use separate databases. Nowadays you can have a very big database
and if you properly designed it you will not have any problem in terms of
perfomance. You probably would not want to maintain many databases all
system calagos and...
If you defined indexes on the tables and do provide tuning the database
searches and updates might be faster so it has not to do with having many
databases.
Also, I'd remove a guest account and make sure that all may users have
appropriate permissions to access the tables.
Don't GRANT them access to underlying tables instead create views to select
data.
Visit on this web site to read more about security of the database
http://vyaskn.tripod.com/sql_server_security_best_practices.htm
http://vyaskn.tripod.com/row_level_security_in_sql_server_databases.htm
"tshad" <tscheiderich@.ftsolutions.com> wrote in message
news:OgCxbGA2EHA.2112@.TK2MSFTNGP15.phx.gbl...
> Scenario: We have an Sql Server system and want to set up a payroll
system.
> We have about 30 tables in this database. We are now going to be handling
> outside companies payroll information.
> Setup 1: One of the fields in the tables would be a company code. This
> would logically separate company A's data from company B's data.
> Our question is on security. How secure is the data if it is all in one
> database? If someone were to hack the database, they could potentially
have
> access to every companies data.
> Setup 2: One way around that would be to replicate the 30 tables for each
> company we bring on board. If we were to have 100 companies, we would
have
> 100 databases and 300 tables.
> This, of course, would be a problem as we make changes to the tables,
since
> we would have to make the changes to the same tables in each of the 100
> databases.
> One benefit to this setup is that if someone were to hack one database,
they
> wouldn't necessarilly have access to other companies data since they would
> be in other database, even though all the databases reside on the same
> machine under the same Sql Server.
> This brings up the issue of multiple machines - which would really be
going
> overboard.
> I am just trying to use due diligence here to see what my possible
problems
> are and whether we could be over thinking the problem.
> Payroll data is very sensitive and we need to make sure we are going far
> enough to protect it, but not too far to make it unwieldy.
> The other question would be whether maybe having all the data in one
> database might slow down the response too much where if we had separate
> databases, searches and updates might be faster.
> Just looking for ideas from others who may have wrestled with these
> questions.
> Thanks,
> Tom.
>
Question on results from Table Joins.
Hi there - i am relatively new to SQL server so please bear with me. I
am attempting to join several tables so that I can generate an asset
report. The query I am runnins is
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location'
--t_catalogs.model as 'Catalog Item Name',
--t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_Teamresponsible_LUT
on t_assets.t_teamresponsible_id =
t_teamresponsible_lut.t_teamresponsible_id
inner join t_internallocations
on t_assets.t_internallocation_id =
t_internallocations.t_internallocation_id
inner join t_activedescriptions_LUT
on t_assets.t_activedescription_id =
t_activedescriptions_LUT.t_activedescription_id
inner join t_category_lut
on t_assets.t_category_id = t_category_lut.t_category_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
My problem is when I run the above query I am getting multiple returns
against the particular surname even though there is only 1 person with
the surname in the particular t_humanresources table. The same is
happening for other fields i have listed as well (although I have
commented these out above).
Does anyone have any ideas as to why this is happening as all I want to
see is a list of Users and the particular hardware assigned to them.
Thanks
Ronnie
<ronnie.walker@.celticgems.co.uk> wrote in message
news:1123857858.974507.278050@.z14g2000cwz.googlegr oups.com...
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
Can't users have more than one piece of hardware assigned to them?
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
|||Try to use Left Join instead of Inner Join.
Perayu
"ronnie.walker@.celticgems.co.uk" wrote:
> Hi there - i am relatively new to SQL server so please bear with me. I
> am attempting to join several tables so that I can generate an asset
> report. The query I am runnins is
> -- Start of Main Select Query
> select t_humanresources.fname as 'First Name',
> t_humanresources.lname as 'Last Name',
> t_humanresources.hridentifier1 as 'HR Identifier',
> t_humanresources.locationid1 as 'Location'
> --t_catalogs.model as 'Catalog Item Name',
> --t_catalogs.manufacturerproductcode
> from T_Catalogs
> inner join t_assets
> on t_catalogs.t_catalog_id = t_assets.t_catalog_id
> inner join t_Teamresponsible_LUT
> on t_assets.t_teamresponsible_id =
> t_teamresponsible_lut.t_teamresponsible_id
> inner join t_internallocations
> on t_assets.t_internallocation_id =
> t_internallocations.t_internallocation_id
> inner join t_activedescriptions_LUT
> on t_assets.t_activedescription_id =
> t_activedescriptions_LUT.t_activedescription_id
> inner join t_category_lut
> on t_assets.t_category_id = t_category_lut.t_category_id
> inner join t_assetusers
> on t_assets.t_asset_id = t_assetusers.t_asset_id
> inner join t_humanresources
> on t_assetusers.t_hr_id = t_humanresources.t_hr_id
> where t_humanresources.Lname = 'Capp'
>
> My problem is when I run the above query I am getting multiple returns
> against the particular surname even though there is only 1 person with
> the surname in the particular t_humanresources table. The same is
> happening for other fields i have listed as well (although I have
> commented these out above).
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
> Thanks
> Ronnie
>
|||On 12 Aug 2005 07:44:19 -0700, ronnie.walker@.celticgems.co.uk wrote:
>Hi there - i am relatively new to SQL server so please bear with me. I
>am attempting to join several tables so that I can generate an asset
>report. The query I am runnins is
(snip)
Hi Ronnie,
In this query, you are joining to several tables that are not used. If
one row from your data matches several rows in those unused tables, the
row will appear to be duplicated - each occurence of the "duplicated"
row is linked to another row in the other table, but you can't see that
because those values are not displayed.
Try what happens if you remove the unused tables:
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location',
t_catalogs.model as 'Catalog Item Name',
t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
And if you comment the two columns you take from t_catalogs, then you
should remove that table from the FROM clause as well.
If the above doesn't help, then see www.aspfaq.com/5006.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
|||On Fri, 12 Aug 2005 11:25:57 -0700, Perayu wrote:
>Try to use Left Join instead of Inner Join.
>Perayu
Hi Perayu,
How would a left join help to remove unwanted duplicates from the
results of the query?
I do see how it might return even more unwanted rows. And how it would
lower performance. But removing duplicates?
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
am attempting to join several tables so that I can generate an asset
report. The query I am runnins is
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location'
--t_catalogs.model as 'Catalog Item Name',
--t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_Teamresponsible_LUT
on t_assets.t_teamresponsible_id =
t_teamresponsible_lut.t_teamresponsible_id
inner join t_internallocations
on t_assets.t_internallocation_id =
t_internallocations.t_internallocation_id
inner join t_activedescriptions_LUT
on t_assets.t_activedescription_id =
t_activedescriptions_LUT.t_activedescription_id
inner join t_category_lut
on t_assets.t_category_id = t_category_lut.t_category_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
My problem is when I run the above query I am getting multiple returns
against the particular surname even though there is only 1 person with
the surname in the particular t_humanresources table. The same is
happening for other fields i have listed as well (although I have
commented these out above).
Does anyone have any ideas as to why this is happening as all I want to
see is a list of Users and the particular hardware assigned to them.
Thanks
Ronnie
<ronnie.walker@.celticgems.co.uk> wrote in message
news:1123857858.974507.278050@.z14g2000cwz.googlegr oups.com...
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
Can't users have more than one piece of hardware assigned to them?
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
|||Try to use Left Join instead of Inner Join.
Perayu
"ronnie.walker@.celticgems.co.uk" wrote:
> Hi there - i am relatively new to SQL server so please bear with me. I
> am attempting to join several tables so that I can generate an asset
> report. The query I am runnins is
> -- Start of Main Select Query
> select t_humanresources.fname as 'First Name',
> t_humanresources.lname as 'Last Name',
> t_humanresources.hridentifier1 as 'HR Identifier',
> t_humanresources.locationid1 as 'Location'
> --t_catalogs.model as 'Catalog Item Name',
> --t_catalogs.manufacturerproductcode
> from T_Catalogs
> inner join t_assets
> on t_catalogs.t_catalog_id = t_assets.t_catalog_id
> inner join t_Teamresponsible_LUT
> on t_assets.t_teamresponsible_id =
> t_teamresponsible_lut.t_teamresponsible_id
> inner join t_internallocations
> on t_assets.t_internallocation_id =
> t_internallocations.t_internallocation_id
> inner join t_activedescriptions_LUT
> on t_assets.t_activedescription_id =
> t_activedescriptions_LUT.t_activedescription_id
> inner join t_category_lut
> on t_assets.t_category_id = t_category_lut.t_category_id
> inner join t_assetusers
> on t_assets.t_asset_id = t_assetusers.t_asset_id
> inner join t_humanresources
> on t_assetusers.t_hr_id = t_humanresources.t_hr_id
> where t_humanresources.Lname = 'Capp'
>
> My problem is when I run the above query I am getting multiple returns
> against the particular surname even though there is only 1 person with
> the surname in the particular t_humanresources table. The same is
> happening for other fields i have listed as well (although I have
> commented these out above).
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
> Thanks
> Ronnie
>
|||On 12 Aug 2005 07:44:19 -0700, ronnie.walker@.celticgems.co.uk wrote:
>Hi there - i am relatively new to SQL server so please bear with me. I
>am attempting to join several tables so that I can generate an asset
>report. The query I am runnins is
(snip)
Hi Ronnie,
In this query, you are joining to several tables that are not used. If
one row from your data matches several rows in those unused tables, the
row will appear to be duplicated - each occurence of the "duplicated"
row is linked to another row in the other table, but you can't see that
because those values are not displayed.
Try what happens if you remove the unused tables:
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location',
t_catalogs.model as 'Catalog Item Name',
t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
And if you comment the two columns you take from t_catalogs, then you
should remove that table from the FROM clause as well.
If the above doesn't help, then see www.aspfaq.com/5006.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
|||On Fri, 12 Aug 2005 11:25:57 -0700, Perayu wrote:
>Try to use Left Join instead of Inner Join.
>Perayu
Hi Perayu,
How would a left join help to remove unwanted duplicates from the
results of the query?
I do see how it might return even more unwanted rows. And how it would
lower performance. But removing duplicates?
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
Question on results from Table Joins.
Hi there - i am relatively new to SQL server so please bear with me. I
am attempting to join several tables so that I can generate an asset
report. The query I am runnins is
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location'
--t_catalogs.model as 'Catalog Item Name',
--t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_Teamresponsible_LUT
on t_assets.t_teamresponsible_id = t_teamresponsible_lut.t_teamresponsible_id
inner join t_internallocations
on t_assets.t_internallocation_id = t_internallocations.t_internallocation_id
inner join t_activedescriptions_LUT
on t_assets.t_activedescription_id = t_activedescriptions_LUT.t_activedescription_id
inner join t_category_lut
on t_assets.t_category_id = t_category_lut.t_category_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
My problem is when I run the above query I am getting multiple returns
against the particular surname even though there is only 1 person with
the surname in the particular t_humanresources table. The same is
happening for other fields i have listed as well (although I have
commented these out above).
Does anyone have any ideas as to why this is happening as all I want to
see is a list of Users and the particular hardware assigned to them.
Thanks
Ronnie<ronnie.walker@.celticgems.co.uk> wrote in message
news:1123857858.974507.278050@.z14g2000cwz.googlegroups.com...
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
Can't users have more than one piece of hardware assigned to them?
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--|||Try to use Left Join instead of Inner Join.
Perayu
"ronnie.walker@.celticgems.co.uk" wrote:
> Hi there - i am relatively new to SQL server so please bear with me. I
> am attempting to join several tables so that I can generate an asset
> report. The query I am runnins is
> -- Start of Main Select Query
> select t_humanresources.fname as 'First Name',
> t_humanresources.lname as 'Last Name',
> t_humanresources.hridentifier1 as 'HR Identifier',
> t_humanresources.locationid1 as 'Location'
> --t_catalogs.model as 'Catalog Item Name',
> --t_catalogs.manufacturerproductcode
> from T_Catalogs
> inner join t_assets
> on t_catalogs.t_catalog_id = t_assets.t_catalog_id
> inner join t_Teamresponsible_LUT
> on t_assets.t_teamresponsible_id => t_teamresponsible_lut.t_teamresponsible_id
> inner join t_internallocations
> on t_assets.t_internallocation_id => t_internallocations.t_internallocation_id
> inner join t_activedescriptions_LUT
> on t_assets.t_activedescription_id => t_activedescriptions_LUT.t_activedescription_id
> inner join t_category_lut
> on t_assets.t_category_id = t_category_lut.t_category_id
> inner join t_assetusers
> on t_assets.t_asset_id = t_assetusers.t_asset_id
> inner join t_humanresources
> on t_assetusers.t_hr_id = t_humanresources.t_hr_id
> where t_humanresources.Lname = 'Capp'
>
> My problem is when I run the above query I am getting multiple returns
> against the particular surname even though there is only 1 person with
> the surname in the particular t_humanresources table. The same is
> happening for other fields i have listed as well (although I have
> commented these out above).
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
> Thanks
> Ronnie
>|||On 12 Aug 2005 07:44:19 -0700, ronnie.walker@.celticgems.co.uk wrote:
>Hi there - i am relatively new to SQL server so please bear with me. I
>am attempting to join several tables so that I can generate an asset
>report. The query I am runnins is
(snip)
Hi Ronnie,
In this query, you are joining to several tables that are not used. If
one row from your data matches several rows in those unused tables, the
row will appear to be duplicated - each occurence of the "duplicated"
row is linked to another row in the other table, but you can't see that
because those values are not displayed.
Try what happens if you remove the unused tables:
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location',
t_catalogs.model as 'Catalog Item Name',
t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
And if you comment the two columns you take from t_catalogs, then you
should remove that table from the FROM clause as well.
If the above doesn't help, then see www.aspfaq.com/5006.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||On Fri, 12 Aug 2005 11:25:57 -0700, Perayu wrote:
>Try to use Left Join instead of Inner Join.
>Perayu
Hi Perayu,
How would a left join help to remove unwanted duplicates from the
results of the query?
I do see how it might return even more unwanted rows. And how it would
lower performance. But removing duplicates?
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)
am attempting to join several tables so that I can generate an asset
report. The query I am runnins is
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location'
--t_catalogs.model as 'Catalog Item Name',
--t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_Teamresponsible_LUT
on t_assets.t_teamresponsible_id = t_teamresponsible_lut.t_teamresponsible_id
inner join t_internallocations
on t_assets.t_internallocation_id = t_internallocations.t_internallocation_id
inner join t_activedescriptions_LUT
on t_assets.t_activedescription_id = t_activedescriptions_LUT.t_activedescription_id
inner join t_category_lut
on t_assets.t_category_id = t_category_lut.t_category_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
My problem is when I run the above query I am getting multiple returns
against the particular surname even though there is only 1 person with
the surname in the particular t_humanresources table. The same is
happening for other fields i have listed as well (although I have
commented these out above).
Does anyone have any ideas as to why this is happening as all I want to
see is a list of Users and the particular hardware assigned to them.
Thanks
Ronnie<ronnie.walker@.celticgems.co.uk> wrote in message
news:1123857858.974507.278050@.z14g2000cwz.googlegroups.com...
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
Can't users have more than one piece of hardware assigned to them?
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--|||Try to use Left Join instead of Inner Join.
Perayu
"ronnie.walker@.celticgems.co.uk" wrote:
> Hi there - i am relatively new to SQL server so please bear with me. I
> am attempting to join several tables so that I can generate an asset
> report. The query I am runnins is
> -- Start of Main Select Query
> select t_humanresources.fname as 'First Name',
> t_humanresources.lname as 'Last Name',
> t_humanresources.hridentifier1 as 'HR Identifier',
> t_humanresources.locationid1 as 'Location'
> --t_catalogs.model as 'Catalog Item Name',
> --t_catalogs.manufacturerproductcode
> from T_Catalogs
> inner join t_assets
> on t_catalogs.t_catalog_id = t_assets.t_catalog_id
> inner join t_Teamresponsible_LUT
> on t_assets.t_teamresponsible_id => t_teamresponsible_lut.t_teamresponsible_id
> inner join t_internallocations
> on t_assets.t_internallocation_id => t_internallocations.t_internallocation_id
> inner join t_activedescriptions_LUT
> on t_assets.t_activedescription_id => t_activedescriptions_LUT.t_activedescription_id
> inner join t_category_lut
> on t_assets.t_category_id = t_category_lut.t_category_id
> inner join t_assetusers
> on t_assets.t_asset_id = t_assetusers.t_asset_id
> inner join t_humanresources
> on t_assetusers.t_hr_id = t_humanresources.t_hr_id
> where t_humanresources.Lname = 'Capp'
>
> My problem is when I run the above query I am getting multiple returns
> against the particular surname even though there is only 1 person with
> the surname in the particular t_humanresources table. The same is
> happening for other fields i have listed as well (although I have
> commented these out above).
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
> Thanks
> Ronnie
>|||On 12 Aug 2005 07:44:19 -0700, ronnie.walker@.celticgems.co.uk wrote:
>Hi there - i am relatively new to SQL server so please bear with me. I
>am attempting to join several tables so that I can generate an asset
>report. The query I am runnins is
(snip)
Hi Ronnie,
In this query, you are joining to several tables that are not used. If
one row from your data matches several rows in those unused tables, the
row will appear to be duplicated - each occurence of the "duplicated"
row is linked to another row in the other table, but you can't see that
because those values are not displayed.
Try what happens if you remove the unused tables:
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location',
t_catalogs.model as 'Catalog Item Name',
t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
And if you comment the two columns you take from t_catalogs, then you
should remove that table from the FROM clause as well.
If the above doesn't help, then see www.aspfaq.com/5006.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||On Fri, 12 Aug 2005 11:25:57 -0700, Perayu wrote:
>Try to use Left Join instead of Inner Join.
>Perayu
Hi Perayu,
How would a left join help to remove unwanted duplicates from the
results of the query?
I do see how it might return even more unwanted rows. And how it would
lower performance. But removing duplicates?
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)
Question on results from Table Joins.
Hi there - i am relatively new to SQL server so please bear with me. I
am attempting to join several tables so that I can generate an asset
report. The query I am runnins is
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location'
--t_catalogs.model as 'Catalog Item Name',
--t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_Teamresponsible_LUT
on t_assets.t_teamresponsible_id =
t_teamresponsible_lut.t_teamresponsible_id
inner join t_internallocations
on t_assets.t_internallocation_id =
t_internallocations.t_internallocation_id
inner join t_activedescriptions_LUT
on t_assets.t_activedescription_id =
t_activedescriptions_LUT.t_activedescription_id
inner join t_category_lut
on t_assets.t_category_id = t_category_lut.t_category_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
My problem is when I run the above query I am getting multiple returns
against the particular surname even though there is only 1 person with
the surname in the particular t_humanresources table. The same is
happening for other fields i have listed as well (although I have
commented these out above).
Does anyone have any ideas as to why this is happening as all I want to
see is a list of Users and the particular hardware assigned to them.
Thanks
Ronnie<ronnie.walker@.celticgems.co.uk> wrote in message
news:1123857858.974507.278050@.z14g2000cwz.googlegroups.com...
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
Can't users have more than one piece of hardware assigned to them?
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--|||Try to use Left Join instead of Inner Join.
Perayu
"ronnie.walker@.celticgems.co.uk" wrote:
> Hi there - i am relatively new to SQL server so please bear with me. I
> am attempting to join several tables so that I can generate an asset
> report. The query I am runnins is
> -- Start of Main Select Query
> select t_humanresources.fname as 'First Name',
> t_humanresources.lname as 'Last Name',
> t_humanresources.hridentifier1 as 'HR Identifier',
> t_humanresources.locationid1 as 'Location'
> --t_catalogs.model as 'Catalog Item Name',
> --t_catalogs.manufacturerproductcode
> from T_Catalogs
> inner join t_assets
> on t_catalogs.t_catalog_id = t_assets.t_catalog_id
> inner join t_Teamresponsible_LUT
> on t_assets.t_teamresponsible_id =
> t_teamresponsible_lut.t_teamresponsible_id
> inner join t_internallocations
> on t_assets.t_internallocation_id =
> t_internallocations.t_internallocation_id
> inner join t_activedescriptions_LUT
> on t_assets.t_activedescription_id =
> t_activedescriptions_LUT.t_activedescription_id
> inner join t_category_lut
> on t_assets.t_category_id = t_category_lut.t_category_id
> inner join t_assetusers
> on t_assets.t_asset_id = t_assetusers.t_asset_id
> inner join t_humanresources
> on t_assetusers.t_hr_id = t_humanresources.t_hr_id
> where t_humanresources.Lname = 'Capp'
>
> My problem is when I run the above query I am getting multiple returns
> against the particular surname even though there is only 1 person with
> the surname in the particular t_humanresources table. The same is
> happening for other fields i have listed as well (although I have
> commented these out above).
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
> Thanks
> Ronnie
>|||On 12 Aug 2005 07:44:19 -0700, ronnie.walker@.celticgems.co.uk wrote:
>Hi there - i am relatively new to SQL server so please bear with me. I
>am attempting to join several tables so that I can generate an asset
>report. The query I am runnins is
(snip)
Hi Ronnie,
In this query, you are joining to several tables that are not used. If
one row from your data matches several rows in those unused tables, the
row will appear to be duplicated - each occurence of the "duplicated"
row is linked to another row in the other table, but you can't see that
because those values are not displayed.
Try what happens if you remove the unused tables:
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location',
t_catalogs.model as 'Catalog Item Name',
t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
And if you comment the two columns you take from t_catalogs, then you
should remove that table from the FROM clause as well.
If the above doesn't help, then see www.aspfaq.com/5006.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||On Fri, 12 Aug 2005 11:25:57 -0700, Perayu wrote:
>Try to use Left Join instead of Inner Join.
>Perayu
Hi Perayu,
How would a left join help to remove unwanted duplicates from the
results of the query?
I do see how it might return even more unwanted rows. And how it would
lower performance. But removing duplicates?
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)
am attempting to join several tables so that I can generate an asset
report. The query I am runnins is
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location'
--t_catalogs.model as 'Catalog Item Name',
--t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_Teamresponsible_LUT
on t_assets.t_teamresponsible_id =
t_teamresponsible_lut.t_teamresponsible_id
inner join t_internallocations
on t_assets.t_internallocation_id =
t_internallocations.t_internallocation_id
inner join t_activedescriptions_LUT
on t_assets.t_activedescription_id =
t_activedescriptions_LUT.t_activedescription_id
inner join t_category_lut
on t_assets.t_category_id = t_category_lut.t_category_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
My problem is when I run the above query I am getting multiple returns
against the particular surname even though there is only 1 person with
the surname in the particular t_humanresources table. The same is
happening for other fields i have listed as well (although I have
commented these out above).
Does anyone have any ideas as to why this is happening as all I want to
see is a list of Users and the particular hardware assigned to them.
Thanks
Ronnie<ronnie.walker@.celticgems.co.uk> wrote in message
news:1123857858.974507.278050@.z14g2000cwz.googlegroups.com...
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
Can't users have more than one piece of hardware assigned to them?
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--|||Try to use Left Join instead of Inner Join.
Perayu
"ronnie.walker@.celticgems.co.uk" wrote:
> Hi there - i am relatively new to SQL server so please bear with me. I
> am attempting to join several tables so that I can generate an asset
> report. The query I am runnins is
> -- Start of Main Select Query
> select t_humanresources.fname as 'First Name',
> t_humanresources.lname as 'Last Name',
> t_humanresources.hridentifier1 as 'HR Identifier',
> t_humanresources.locationid1 as 'Location'
> --t_catalogs.model as 'Catalog Item Name',
> --t_catalogs.manufacturerproductcode
> from T_Catalogs
> inner join t_assets
> on t_catalogs.t_catalog_id = t_assets.t_catalog_id
> inner join t_Teamresponsible_LUT
> on t_assets.t_teamresponsible_id =
> t_teamresponsible_lut.t_teamresponsible_id
> inner join t_internallocations
> on t_assets.t_internallocation_id =
> t_internallocations.t_internallocation_id
> inner join t_activedescriptions_LUT
> on t_assets.t_activedescription_id =
> t_activedescriptions_LUT.t_activedescription_id
> inner join t_category_lut
> on t_assets.t_category_id = t_category_lut.t_category_id
> inner join t_assetusers
> on t_assets.t_asset_id = t_assetusers.t_asset_id
> inner join t_humanresources
> on t_assetusers.t_hr_id = t_humanresources.t_hr_id
> where t_humanresources.Lname = 'Capp'
>
> My problem is when I run the above query I am getting multiple returns
> against the particular surname even though there is only 1 person with
> the surname in the particular t_humanresources table. The same is
> happening for other fields i have listed as well (although I have
> commented these out above).
> Does anyone have any ideas as to why this is happening as all I want to
> see is a list of Users and the particular hardware assigned to them.
> Thanks
> Ronnie
>|||On 12 Aug 2005 07:44:19 -0700, ronnie.walker@.celticgems.co.uk wrote:
>Hi there - i am relatively new to SQL server so please bear with me. I
>am attempting to join several tables so that I can generate an asset
>report. The query I am runnins is
(snip)
Hi Ronnie,
In this query, you are joining to several tables that are not used. If
one row from your data matches several rows in those unused tables, the
row will appear to be duplicated - each occurence of the "duplicated"
row is linked to another row in the other table, but you can't see that
because those values are not displayed.
Try what happens if you remove the unused tables:
-- Start of Main Select Query
select t_humanresources.fname as 'First Name',
t_humanresources.lname as 'Last Name',
t_humanresources.hridentifier1 as 'HR Identifier',
t_humanresources.locationid1 as 'Location',
t_catalogs.model as 'Catalog Item Name',
t_catalogs.manufacturerproductcode
from T_Catalogs
inner join t_assets
on t_catalogs.t_catalog_id = t_assets.t_catalog_id
inner join t_assetusers
on t_assets.t_asset_id = t_assetusers.t_asset_id
inner join t_humanresources
on t_assetusers.t_hr_id = t_humanresources.t_hr_id
where t_humanresources.Lname = 'Capp'
And if you comment the two columns you take from t_catalogs, then you
should remove that table from the FROM clause as well.
If the above doesn't help, then see www.aspfaq.com/5006.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||On Fri, 12 Aug 2005 11:25:57 -0700, Perayu wrote:
>Try to use Left Join instead of Inner Join.
>Perayu
Hi Perayu,
How would a left join help to remove unwanted duplicates from the
results of the query?
I do see how it might return even more unwanted rows. And how it would
lower performance. But removing duplicates?
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)
question on renaming columns
Hi,
Quick question!
Is there anyway to rename a column such that it reflects all columns on all reference tables, stored procedures,views, etc.,
Ex. table1 is with col1 (primary key)
table2 with col2, col1(FK--table1(col1)
if i try to rename col1 on table1 it has to rename col1 on table2 automatically.
Any help is greatly appreciated.
-SSFirst, buy a magic wand....
I've left typos alone because it wasn't worth the risk...or energy...
Quick question!
Is there anyway to rename a column such that it reflects all columns on all reference tables, stored procedures,views, etc.,
Ex. table1 is with col1 (primary key)
table2 with col2, col1(FK--table1(col1)
if i try to rename col1 on table1 it has to rename col1 on table2 automatically.
Any help is greatly appreciated.
-SSFirst, buy a magic wand....
I've left typos alone because it wasn't worth the risk...or energy...
Question on Relationships
Hello,
I'm interested to know whats the difference between a many to one
relationship and a one to many relationship. Presuming 2 tables A and B
A (1 to many) B relationship is different with B (many to 1) A relationship?
I've thought that they're the same but I was watching a BI webcast when they
say that the logical relationship cannot be reversed...
Can someone enlighten this?They are the same relationship, just viewed from opposite perspectives.
I guess by saying the logical relationship cannot be reversed they mean
that if you can get the "1" row from a particular "many" row that does
not imply that you can then get back to the original "many" row just
given that "1" row (because there are now many rows that match up with
that 1 row). Does that make sense? (That's just a guess at what they
were trying to explain (not having any idea what they were saying
exactly) - maybe you could ask the presenter directly what they meant
precisely.)
*mike hodgson*
http://sqlnerd.blogspot.com
Nestor wrote:
>Hello,
>I'm interested to know whats the difference between a many to one
>relationship and a one to many relationship. Presuming 2 tables A and B
>A (1 to many) B relationship is different with B (many to 1) A relationship
?
>I've thought that they're the same but I was watching a BI webcast when the
y
>say that the logical relationship cannot be reversed...
>Can someone enlighten this?
>
>
I'm interested to know whats the difference between a many to one
relationship and a one to many relationship. Presuming 2 tables A and B
A (1 to many) B relationship is different with B (many to 1) A relationship?
I've thought that they're the same but I was watching a BI webcast when they
say that the logical relationship cannot be reversed...
Can someone enlighten this?They are the same relationship, just viewed from opposite perspectives.
I guess by saying the logical relationship cannot be reversed they mean
that if you can get the "1" row from a particular "many" row that does
not imply that you can then get back to the original "many" row just
given that "1" row (because there are now many rows that match up with
that 1 row). Does that make sense? (That's just a guess at what they
were trying to explain (not having any idea what they were saying
exactly) - maybe you could ask the presenter directly what they meant
precisely.)
*mike hodgson*
http://sqlnerd.blogspot.com
Nestor wrote:
>Hello,
>I'm interested to know whats the difference between a many to one
>relationship and a one to many relationship. Presuming 2 tables A and B
>A (1 to many) B relationship is different with B (many to 1) A relationship
?
>I've thought that they're the same but I was watching a BI webcast when the
y
>say that the logical relationship cannot be reversed...
>Can someone enlighten this?
>
>
Subscribe to:
Posts (Atom)