Select
A.field1,B.field2
from DB1.user.tablename A inner join DB2.user.tablename B
on A.ID = B.ID
C|||Actually I do not want to hard code the database name in the query. Can I use the datasources somehow?|||I have not been able to query across datasources.
If you just want to query one db, then you could create a view in one db that queries both dbs.
Nevermind. I didn't realize that the report model definition had to be refreshed.
yes u can do this using sp_rename system stored procedure . read more in BOL
Madhu
|||As Madhu indicated, use sp_rename.
EXECUTE sp_rename 'tablename', 'TableName', object
|||Thank you all for help, 'sp_rename' works fine.The heart of it is a cursor that selects records from joins on this basis:
SELECT <a bunch of fields>
FROM Property d
JOIN PropTypeMap ptm ON ptm.PropertyTypeID = d.PropertyTypeID
JOIN PropertyID a ON a.PropID = d.PropID
JOIN Event e1 ON e1.PropID = d.PropID
LEFT OUTER JOIN Event e2 ON e2.PropID = d.PropID
WHERE
d.LastSaleDate >= @.LoDate
AND a.GeoLongitude BETWEEN @.LowerLon AND @.UpperLon
AND a.GeoLatitude BETWEEN @.LowerLat AND @.UpperLat
AND ptm.PropCategory = @.PropType
AND a.GeoMatch <= @.MinGeoQuality
AND e1.EventTypeID = @.SaleEventType
AND e1.TransactionType = 'R'
AND e1.EventDt BETWEEN @.LoDate AND @.HiDate
AND e1.EventAmt > 0
AND e2.EventTypeID = @.AssessmentEventType
AND e2.EventDt <= @.HiDate
AND e2.EventAmt > 0
Each property has one PropertyID record, one Property record, and N Event
records (average perhaps five).
What is the mystery? If @.HiDate, which is the upper end of the time window,
is 2002-11-08 or earlier, nothing is returned. If it's 2002-11-09 or later,
oodles of records are found. I get the same query plan for either one, and
based on the content of the data, they should return almost exactly the same
set of records -- exactly the same set in almost all cases, in fact.
Is 2002-11-08/09 some sort of magic dividing point? I have replicated this
on the large database and on a smaller test version on another SQL Server.
(SQL Server 2000) I dropped the indexes and tried it, and
the same thing happened. This is driving me crazy![posted and mailed, please reply in news]
Jim Geissman (jim_geissman@.countrywide.com) writes:
> What is the mystery? If @.HiDate, which is the upper end of the time
> window, is 2002-11-08 or earlier, nothing is returned. If it's
> 2002-11-09 or later, oodles of records are found. I get the same query
> plan for either one, and based on the content of the data, they should
> return almost exactly the same set of records -- exactly the same set in
> almost all cases, in fact.
> Is 2002-11-08/09 some sort of magic dividing point? I have replicated
> this on the large database and on a smaller test version on another SQL
> Server. (SQL Server 2000) I dropped the indexes and tried it, and the
> same thing happened. This is driving me crazy!
Without access to the database, or a script that reproduces the problem,
there is much left for me, but to guess.
And the obvious guess is that the rows you find are from 2002-11-08, but
have a time porttion, and thus are > '2002-11-08 00:00:00'.
However, I notice one thing with your query which may not be correct:
LEFT OUTER JOIN Event e2 ON e2.PropID = d.PropID
WHERE ...
AND e2.EventTypeID = @.AssessmentEventType
AND e2.EventDt <= @.HiDate
AND e2.EventAmt > 0
The idea with a left outer join is that you include rows in the left
table, even if there is no matching rows in the right table. The
columns in the right table are then set to NULL.
Now, the FROM clause is (logically) evaluated before the WHERE clause,
which acts on the filter on the table defined by the FROM clause. This
means that you will filter away those rows with NULL in e2.EventTypeID
that comes from the outer join. Your join is now effectively an inner
join.
There are two ways to handle this:
1) Add conditions with OR clauses or coalesce to handle NULL in the WHERE
clause.
2) Move the conditions to the ON clause.
--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thanks, Erland. You hit the nail on the head. I was naively assuming that
the right side of the Left Outer Join didn't matter, but when I removed the
second condition in the excerpt below, the records all appeared. As you
said, it was because the FROM was being evaluated before the WHERE. Moving
the condition to ON fixed it. Thanks. I wonder if I have any other
scripts that make this mistake...
> However, I notice one thing with your query which may not be correct:
> LEFT OUTER JOIN Event e2 ON e2.PropID = d.PropID
> WHERE ...
> AND e2.EventTypeID = @.AssessmentEventType
> AND e2.EventDt <= @.HiDate
> AND e2.EventAmt > 0
> The idea with a left outer join is that you include rows in the left
> table, even if there is no matching rows in the right table. The
> columns in the right table are then set to NULL.
> Now, the FROM clause is (logically) evaluated before the WHERE clause,
> which acts on the filter on the table defined by the FROM clause. This
> means that you will filter away those rows with NULL in e2.EventTypeID
> that comes from the outer join. Your join is now effectively an inner
> join.
> There are two ways to handle this:
> 1) Add conditions with OR clauses or coalesce to handle NULL in the WHERE
> clause.
> 2) Move the conditions to the ON clause.|||Jim Geissman (jim_geissman@.countrywide.com) writes:
> Thanks, Erland. You hit the nail on the head. I was naively assuming
> that the right side of the Left Outer Join didn't matter, but when I
> removed the second condition in the excerpt below, the records all
> appeared. As you said, it was because the FROM was being evaluated
> before the WHERE. Moving the condition to ON fixed it. Thanks. I
> wonder if I have any other scripts that make this mistake...
A very common mistake to make. I recall that I did it myself a few
times when I switched to the new syntax from the old *= crap.
--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp
I'm trying to track down a mysterious problem we're experiencing in
which updates and inserts to tables in our mssql2k server appear to be
'disappearing.'
To explain our situation:
We have a web page (written in ASP, if that's relevant) on which we
accept enrollment information.
When that page is submitted, the form data is passed to a stored
procedure on our mssql2k server, which performs several operations,
all of which are wrapped in a transaction.
In particular, the stored procedure performs an update operation on a
record in one table (i'll call it TableA) and an insert into another
table (TableB).
If the procedure encounters a problem (ie after each update / insert
operation in the procedure we test for IF @.@.Error<>0) it performs a
rollback, performs a select similar to the one immediately below, and
then RETURNs.
SELECT '1' as error, 'Unable to update TableA' as errormsg
If the procedure doesn't fail any of the @.@.Error tests, the
transaction is committed, and a membership number is SELECTed to be
returned.
SELECT '0' as error, @.memnum as membershipnumber
The @.memnum variable is populated within the transaction.
Back in the ASP page we test both for the proc returning an empty
recordset, or for it passing an explicit value in the error field, and
push the page to an error page if either of these conditions are met.
If, on the other hand, none of these conditions are met, and the
membershipnumber field in the recordset is populated with a valid
membership number, we push to a confirmation page.
This confirmation page receives the membership number in a session
variable, performs a SELECT against TableB (the table that received
the insert during the proc) using that membership number in the WHERE
clause, and the resultant recordset is used to populate the
confirmation details on that page. That recordset is also then used to
populate the details of a confirmation email, which is automatically
sent by the confirmation page.
And now here's our problem: we've become aware of a handfull of people
who have gone through the enrollment process, have received the
confirmation email containing the information they supplied as
expected, but the data appears to be entirely missing from our tables.
By that I mean that the record in TableA does not appear to have been
updated (under normal circumstances that record should have had
several flags set, and several other fields updated with information
supplied by the person enrolling), and the record in TableB does not
appear to have been inserted.
In essence, looking at our tables, it *feels* like the transaction in
the stored procedure for that particular enrollment hit a problem and
was rolled back. However, the evidence that we have in the form of the
confirmation email argues strongly that the data must have existed in
our tables (particularly in TableB), if only for an unknown period of
time.
We're kind of at our wit's end to work out what is going wrong with
these enrollments. From my understanding of transactions (and I could
well be wrong) any changes to data (ie updates, inserts etc) contained
within are essentially 'invisible' to any other operation (ie the
SELECT that happens in the confirmation page) until the transaction is
committed, implying that the effect of the update and insert should
have been 'permanently' successful if no error code is received and if
a valid membership number was returned. I ask, because someone in our
team has suggested that maybe the operations in the transaction
'lasted long enough' in the tables to have been visible for the SELECT
on the confirmation page to have worked, but were then subsequently
rolled back, explaining why the confirmation email is appropriately
populated and why the data then appears to be missing. However, as I
said, this doesn't match my understanding of how transactions behave.
Sorry for the length of this post, but I felt it was best to explain
this as best as I could.
Does anyone have any advice they can give us on this situation? ie,
are there any known problems with operations in transactions 'bleeding
over' into tables, but then being rolled back at some later point?
Does anyone have any thoughts or suggestions on how we can further
diagnose this issue?
Truly, any help will be immensely appreciated...
Thanks in advance,
M Wells"M Wells" <planetthoughtful@.gmail.com> wrote in message
news:hmba41p1gvtsmudtbus027ad3rapgo1ghd@.4ax.com...
> Hi All,
> I'm trying to track down a mysterious problem we're experiencing in
> which updates and inserts to tables in our mssql2k server appear to be
> 'disappearing.'
> To explain our situation:
> We have a web page (written in ASP, if that's relevant) on which we
> accept enrollment information.
<snip
First, to address your question about data inside a transaction being
visible to other connections, this would only happen if the other connection
explicitly sets its transaction level to READ UNCOMMITTED, which would allow
it to see data which has been inserted/updated but not committed. See SET
TRANSACTION ISOLATION LEVEL in Books Online for more details - I suppose
your ASP connections could be setting this isolation level, but it isn't the
default, so it would be somewhat unusual.
As for tracking down what's going on with the data, you can use Profiler to
run a trace, perhaps filtered on those specific tables and any relevant
stored procedures. If this problem happens fairly often, then running it
interactively may be possible, otherwise see the sp_trace_% procs in Books
Online for details of setting up a server-side trace.
You might also want to check for any triggers on the tables, as sometimes
they can be fired at times you don't expect. And if you have a middle tier
layer, you could also see if it's initiating a transaction before calling
the procedure - it could be that the procedure itself commits correctly, and
the email is sent, but there's an additional outer transaction started by
the middle tier which is then sometimes rolled back after sending the email.
Checking @.@.TRANCOUNT inside the procedure would give you a clue.
Simon|||M Wells (planetthoughtful@.gmail.com) writes:
> If the procedure doesn't fail any of the @.@.Error tests, the
> transaction is committed, and a membership number is SELECTed to be
> returned.
> SELECT '0' as error, @.memnum as membershipnumber
> The @.memnum variable is populated within the transaction.
> Back in the ASP page we test both for the proc returning an empty
> recordset, or for it passing an explicit value in the error field, and
> push the page to an error page if either of these conditions are met.
> If, on the other hand, none of these conditions are met, and the
> membershipnumber field in the recordset is populated with a valid
> membership number, we push to a confirmation page.
> This confirmation page receives the membership number in a session
> variable, performs a SELECT against TableB (the table that received
> the insert during the proc) using that membership number in the WHERE
> clause, and the resultant recordset is used to populate the
> confirmation details on that page. That recordset is also then used to
> populate the details of a confirmation email, which is automatically
> sent by the confirmation page.
> And now here's our problem: we've become aware of a handfull of people
> who have gone through the enrollment process, have received the
> confirmation email containing the information they supplied as
> expected, but the data appears to be entirely missing from our tables.
As I understand, this is an intermittent problem, and you don't have a
reproducible scenario. This make such a problem much more difficult
to track down. And if you make changes to address, you cannot really
be sure that you fixed the right thing.
One thing that is not clear to me is whether it is the same SQL Server
process that runs the stored procedure and the gets the data to the
confirmation page, or whether they are two different. (I should butt
in that I don't know ASP or IIS, so this talk about session variables
etc, tells me little.)
If it is the same SQL Server process, here is something that could
happen:
1) The stored procedure first run unsuccessfully, and a transaction
is started, but then neither committed nor rolled back.
2) The process then runs the procedure successfully, and then gets
the data to the confirmation page. This time a nested transaction
was started and committed. However, "commit" in the case of an
inner transaction just means that transaction count is decremented.
3) The process goes on and registers and confirms more enrollments.
4) Eventually the process is logged out, still with an open transaction.
All enrollments are now rolled back.
So why in step 1, would this happen? It can be a coding error in
the stored procedure, so that a rollback is not executed when it
should. But it could also be a client-side thing. Say that the
procedure is blocked for some reason, and the client gets a command
timeout. In this case the transaction started by the stored procedure
is *not* rolled back. This a really nasty gotcha.
If the confirmation page is really a separate SQL Server connection -
and you should really use the SQL Server Profiler to verify this - then
the data has been committed, and thus it has later been removed. Well,
if the confirmation reads with NOLOCK, are back to the previous
scenario.
One thing you should investigate in either case, is whether these missing
enrollments happened at different points in time, or if they are clustered.
That could give a clue of what may have happened.
I hope this has given you some more ideas of what to look for.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp
