|
velmahesh wrote: Please,Dont Forget to click Accept Answer and Click vote.. Earn
Points.
That's an automatic 1.
|
|
|
|
|
Hi All,
I have 3 reports that run fine individually showing headers and data. The queries use no parameters just a calculated date within the query.
I'm trying to place all 3 reports (They are related but do not require each other)into one document as this is the user requirement and thought that this would be easy using the sub-report feature.
I've taken 1 report and tried dragging and dropping one of the other reports onto the report layout designer where it appears as a grey box with the name of the report in the centre. I've checked the visibility is set to visible and data output is set to Yes (I'm guessing here).
When I preview the report the first report shows fine, i.e. the one I started with, but subsequent reports do not show at all - header or data.
Googling the issue makes me think I'm doing something fundamentally wrong as I can't find a post that outlines the same issue.
Any ideas?
Cheers
Paul
|
|
|
|
|
I've just found out (by accident) that sub-reports in my version of BID do not preview - Once deployed they show up fine.
|
|
|
|
|
Guru's,
I have the following SQL query and it gives me back some syntactical errors and I am not familiar enough with Sql Server to understand exactly what it is I am doing wrong. Thanks in advance for an information!
ALTER TABLE BatchData
DROP CONSTRAINT PK_BatchData
ALTER COLUMN StartTime VARCHAR(50) NOT NULL
ADD PRIMARY KEY (BatchID,StartTime)
Gives error:
Msg 156, Level 15, State 1, Line 3
Incorrect syntax near the keyword 'COLUMN'.
|
|
|
|
|
From what I can tell, you are trying to perform three actions:
drop constraint
alter column
add primary key
Each action must be completed separately, so:
ALTER TABLE BatchData
DROP CONSTRAINT PK_BatchData
ALTER TABLE BatchData
ALTER COLUMN StartTime VARCHAR(50) NOT NULL
ALTER TABLE BatchData
ADD PRIMARY KEY (BatchID,StartTime)
Does that help?
Tim
|
|
|
|
|
Member 8003276 wrote: ADD PRIMARY KEY (BatchID,StartTime)
Try:
ALTER TABLE BatchData
ADD CONSTRAINT PK_BatchData PRIMARY KEY (BatchID, StartTime);
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
When I run this:
DECLARE @voter_id INT
SET @Command = 'SELECT @voter_id = voterid FROM tblCamp_CT WHERE ' + @Query
EXEC (@Command)
I get the error
Must declare the scalar variable "@voter_id".
Why is this happening????
Everything makes sense in someone's mind
|
|
|
|
|
You must include DECLARE @voter_id INT inside single quotes.
e.g
SET @Command = 'DECLARE @voter_id INT SELECT @voter_id = voterid FROM tblCamp_CT WHERE ' + @Query
EXEC (@Command)
I Love T-SQL
"Don't torture yourself,let the life to do it for you."
If my post helps you kindly save my time by voting my post.
www.cacttus.com
|
|
|
|
|
But if I declare it in the @Command string, I cannot use @voter_id outside the string, correct?
I still get the same error message because @voter_id only exists in the string.
Everything makes sense in someone's mind
|
|
|
|
|
Absolutely.
Dasblinkenlight's solution is a nice one to the problem, BTW.
I normally build a temp table and just run the data into that. Using an insert or an update.
I know it seems (both suggested solutions) like a lot of overhead to get one piece of data out but that's really what it takes.
create table #Value (
val int
)
set @command = 'insert into #value (val) SELECT top 1 voterid FROM tblCamp_CT WHERE ' +@Query
exec(@command)
set @voter_id=(select top 1 val from #Value)
delete #Value
Like that.
You could also research sp_executesql for your project.
this works, for example:
declare @voter_id int , @query varchar(max), @command nvarchar(4000)
,@parm nvarchar(20)
set @query='1=1'
SET @Command = 'SELECT top 1 @voter_id = voterid FROM tblCamp_CT WHERE ' + @Query
set @parm ='@voter_id int output '
exec sp_executesql @command,@parm ,@voter_id out
select @voter_id test
As you can see the sp_executesql gives you another option.
Some of this depends on what your personal flavor is toward a given solution.
_____________________________
Give a man a mug, he drinks for a day. Teach a man to mug...
|
|
|
|
|
Blue Boy is correct.
The 'why' of it is that the context has shifted. The exec runs inside of it's own little world that has no idea of what occurred outside of the @command string.
You can see a similar effect whenever you hit a 'go' statement. Variables become undeclared because the context has changed. The difference is that when you run an exec it doesn't break the context outside of the exec the way 'go' does.
_____________________________
Give a man a mug, he drinks for a day. Teach a man to mug...
|
|
|
|
|
Others have answered the 'why' question, so let's go straight to the 'how' part.
As clever as it may seem, your trick does not work, because SQL server does not let you parameterize dynamic SQL. However, you can trick it by observing that dynamic SQL is essentially an anonymous stored procedure; once you give it a name, you can start passing parameters to it.
|
|
|
|
|
That would be another reason not to use stored procedures. Things like that are so much simpler when the SQL is in your DAL.
|
|
|
|
|
PIEBALDconsult wrote: That would be another reason not to use stored procedures
Boo, hissss, brrrppp and other sundry rude noises. Oh wait we've been round this tree before.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
PIEBALDconsult wrote:
That would be another reason not to use
stored procedures. Things like that are so much simpler when the SQL is in your
DAL.
I'll bite, this is easy in a proc. Seems like it would be way more difficult embedded in the DAL. I'm interested in how you would accomplish it?
EXEC sp_executesql @DYNA_SQL, N'@NUM_ROWS int out'
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
What does it do? 
|
|
|
|
|
Pretty much the same thing that smcnulty2000 suggested doing in the second suggestion. sp_executesql allows for parameters to be fed in / out the dynamic SQL being executed.
http://msdn.microsoft.com/en-us/library/ms188001.aspx[^]
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
Here are a couple of simple examples. Not using my usual data access classes.
I prefer the ExecuteScalar, it was designed for this sort of thing.
System.Data.IDbConnection dbc = new System.Data.SqlClient.SqlConnection
(
@"Server='localhost\SQLEXPRESS'; Database='Rubbish'; Trusted_Connection='True'"
) ;
System.Data.IDbCommand cmd = dbc.CreateCommand() ;
cmd.CommandText = "SELECT @voter_id=Id FROM Account WHERE " + "Name = 'Two'" ;
System.Data.IDbDataParameter prm = cmd.CreateParameter() ;
prm.ParameterName = "@voter_id" ;
prm.DbType = System.Data.DbType.Int32 ;
prm.Direction = System.Data.ParameterDirection.Output ;
cmd.Parameters.Add ( prm ) ;
dbc.Open() ;
cmd.ExecuteNonQuery() ;
int id = (int) prm.Value ;
cmd.Parameters.Clear() ;
cmd.CommandText = "SELECT Id FROM Account WHERE " + "Name = 'Three'" ;
object o = cmd.ExecuteScalar() ;
if ( o != System.DBNull.Value )
{
id = (int) o ;
}
dbc.Close() ;
|
|
|
|
|
Interesting, those are not very far off from I have used in code. Though most of my work is all database level work now (data warehousing, stored procs, SSIS, SSAS and SSRS), so I've come to use stored procs for everything. Just seems easier to me.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
S Douglas wrote: I've come to use stored procs for everything
They are rarely the right tool for the job.
|
|
|
|
|
PIEBALDconsult wrote: They are rarely the right tool for the job.
No other tool suits the needs,  . I don't disagree with you sediments. However, in my world its all that exists.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
Here's another take on it:
public static T
GetAccountId<T>
(
this System.Data.IDbConnection dbc
,
string Filter
,
params System.Tuple<string,object>[] Parameters
)
{
T result = default(T) ;
System.Data.IDbCommand cmd = dbc.CreateCommand() ;
cmd.CommandText = "SELECT Id FROM Account WHERE " + Filter ;
if ( Parameters != null )
{
foreach ( System.Tuple<string,object> p in Parameters )
{
System.Data.IDbDataParameter prm = cmd.CreateParameter() ;
prm.ParameterName = p.Item1 ;
prm.Value = p.Item2 ;
cmd.Parameters.Add ( prm ) ;
}
}
dbc.Open() ;
object o = cmd.ExecuteScalar() ;
if ( o != System.DBNull.Value )
{
result = (T) o ;
}
dbc.Close() ;
return ( result ) ;
}
|
|
|
|
|
Dear All,
I have one table with column called testId. This Id is referenced in six other table columns.
Its not like a primary /foreign key type but can be used to compare values using inner join.
There is a requirement to changed all of this testId(10 digits code originally) to new set of TestId(11 digits code now).
I could have done ON UPDATE CASCADE to change all testid's in other six tables if there was primary /foreign key defined.
Is there any one who can give me a hint on the script to update on the master table so that all the other tables will contain the relevant changes on the testId.
For example : Old value New Value
testId = s401 I00010
s402 I00020
s403 I00030
s403 I00040
This is going be applied to over 30k rows hence i just needed a script to do it.
Thank you so much for your time.
<div class="modified">modified on Wednesday, July 13, 2011 5:37 PM</div>
|
|
|
|
|
What did you do so far to archive your query? Can you show us your query?
I Love T-SQL
"Don't torture yourself,let the life to do it for you."
If my post helps you kindly save my time by voting my post.
www.cacttus.com
|
|
|
|
|
It is always a good idea to have foreign key relationships on tables. Creating indexes on the foreign keys will also speed up queries.
Why don't you try creating the foreign key relationships now with the ON UPDATE CASCADE option?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
