Print Control

Hi guys
The Print control - printing directly from the Report Manager - have a
default setting. Is there a way to change this default setting'
Our problem is that the default is 5*8 letter format whereas here we use A4
format. Preferable it would pickup the report format in regards to portrait
or landscape.
Thanks.
Regards
JonasIt should pick this up. Check and see what your page layout size is.
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Jonas Larsen" <JonasLarsen@.discussions.microsoft.com> wrote in message
news:CB2C2B3D-CAD3-4565-AB2F-8E134D8D0243@.microsoft.com...
> Hi guys
> The Print control - printing directly from the Report Manager - have a
> default setting. Is there a way to change this default setting'
> Our problem is that the default is 5*8 letter format whereas here we use
> A4
> format. Preferable it would pickup the report format in regards to
> portrait
> or landscape.
> Thanks.
> Regards
> Jonas|||I have a report that have this:
<PageHeight>29.7cm</PageHeight>
<PageWidth>42cm</PageWidth>
Which matches A3 landscape but ends up as 8,5 by 11". This report does have
page header and footer does that matter?
I must admit that it does pickup A3 & A4 formats on some other reports.
Thanks.
Regards
Jonas
"Bruce L-C [MVP]" wrote:
> It should pick this up. Check and see what your page layout size is.
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Jonas Larsen" <JonasLarsen@.discussions.microsoft.com> wrote in message
> news:CB2C2B3D-CAD3-4565-AB2F-8E134D8D0243@.microsoft.com...
> > Hi guys
> >
> > The Print control - printing directly from the Report Manager - have a
> > default setting. Is there a way to change this default setting'
> >
> > Our problem is that the default is 5*8 letter format whereas here we use
> > A4
> > format. Preferable it would pickup the report format in regards to
> > portrait
> > or landscape.
> >
> > Thanks.
> >
> > Regards
> > Jonas
>
>|||Weird, it picks it up for some but not all. All I can suggest is to see if
there is anything different between the reports that work and those that
doesn't.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Jonas Larsen" <JonasLarsen@.discussions.microsoft.com> wrote in message
news:33FEE50C-2C84-41D9-A23E-998C30BCDB10@.microsoft.com...
>I have a report that have this:
> <PageHeight>29.7cm</PageHeight>
> <PageWidth>42cm</PageWidth>
> Which matches A3 landscape but ends up as 8,5 by 11". This report does
> have
> page header and footer does that matter?
> I must admit that it does pickup A3 & A4 formats on some other reports.
> Thanks.
> Regards
> Jonas
> "Bruce L-C [MVP]" wrote:
>> It should pick this up. Check and see what your page layout size is.
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Jonas Larsen" <JonasLarsen@.discussions.microsoft.com> wrote in message
>> news:CB2C2B3D-CAD3-4565-AB2F-8E134D8D0243@.microsoft.com...
>> > Hi guys
>> >
>> > The Print control - printing directly from the Report Manager - have a
>> > default setting. Is there a way to change this default setting'
>> >
>> > Our problem is that the default is 5*8 letter format whereas here we
>> > use
>> > A4
>> > format. Preferable it would pickup the report format in regards to
>> > portrait
>> > or landscape.
>> >
>> > Thanks.
>> >
>> > Regards
>> > Jonas
>>

Print

Hello Guys,

Is it Possible to receive the PRINT Message from a Stored Procedure in the applications?

If no, how SQL Entrerpris Manager receives the print generated from the RESTORE DATABASE WIHT STAT ?

RESTORE DATABASE [dbProdApp]
FROM DISK = N'C:\S_HOMSQL_Db_20030513_dbProdSys_Temp_Manual.ba k'
WITH
FILE = 1,
NOUNLOAD ,
STATS = 10,
RECOVERY ,
REPLACE ,
MOVE N'dbSolomonProdSys_Log' TO N'c:\dbProdSys_Temp_log.ldf',
MOVE N'dbSolomonProdSys_Data' TO N'c:\dbProdSys_Temp.mdf'

Thankxs Everybody!You can mention PRINT statement in the SP to get the information. Refer to books online for PRINT topic.|||BUt I'd like to receive the print messages in a ASP application for example.

Or save the messages in a temporary table.sql

Primary Key, bigint or char?

Hey guys, just a quick question for you. I think I know the answer, but I
would like to get the expert's opinions...
I have a primary key called RequestID that is to be constructed of the
year, month, day, and a four-digit sequence number with leading zeros. An
example of the ninth Request placed today would be:
200506090009
As well as being the primary key, this field will be used in WHERE clauses
and in joins to several other tables in my schema.
My question is; should the data type be bigint or char(12)?Well, judging by size, I would choose the bigint since it is only 8 bytes
instead of the 12 bytes that are used by a char(12). I am not sure on this,
but I would assume that searching on an int would be faster. Again, that is
pure speculation on my part and I have no way to back it up. Just my 2￠.
Chris
"Tim Baur" wrote:

> Hey guys, just a quick question for you. I think I know the answer, but I
> would like to get the expert's opinions...
> I have a primary key called RequestID that is to be constructed of the
> year, month, day, and a four-digit sequence number with leading zeros. An
> example of the ninth Request placed today would be:
> 200506090009
> As well as being the primary key, this field will be used in WHERE clauses
> and in joins to several other tables in my schema.
> My question is; should the data type be bigint or char(12)?
>|||>> As well as being the primary key, this field will be used in WHERE
Logically, the data type of an attribute is often decided based on the
operations applicable on its values. Therefore as a primary consideration,
identify the potential operations -- either integer specific or character
specific -- and use that for determining the type.
Also, physical factors like storage size of the values, potential
performance implications etc. can be a valid considerations during specific
implementation, depending on how the queries are formulated and how the data
is updated. So 8 bytes vs. 12 bytes, esp. in a large table often tend to
favor smaller size datatype, esp. for key columns.
Anith|||"Anith Sen" <anith@.bizdatasolutions.com> wrote in
news:ePLNgaTbFHA.3932@.TK2MSFTNGP12.phx.gbl:

> Logically, the data type of an attribute is often decided based on the
> operations applicable on its values. Therefore as a primary
> consideration, identify the potential operations -- either integer
> specific or character specific -- and use that for determining the
> type.
> Also, physical factors like storage size of the values, potential
> performance implications etc. can be a valid considerations during
> specific implementation, depending on how the queries are formulated
> and how the data is updated. So 8 bytes vs. 12 bytes, esp. in a large
> table often tend to favor smaller size datatype, esp. for key columns.
>
Thank you, Chris and Anith, for your input. I also suspect that bigint is
the best choice, but because it is numeric more than size considerations.
If given the choice between char(8) and bigint I would still choose bigint.
I know from general programming experience that numeric lists are faster to
index, sort, and search than strings. I suspect that SQL Server wouldn't
be any different in this, but that is just a guess. I would be curious to
hear the definitive answer on the topic.|||Well, I am definitely not an expert, but I definitely have opinions, so here
goes...
May I choose super-secret option number three, "None of the Above"? How
about using a two-column key, consisting of RequestDate(smalldatetime) and
RequestNumber(smallint)? This would provide the following benefits:
1) Uses two less bytes than a bigint (bigint = 8 bytes, smalldatetime = 4
bytes and smallint = 2 bytes)
2) You get a larger set of available numbers for RequestNumber - 10000 in
you setup versus 32000+ in my setup (if you only use the positive values).
3) Makes standard types of calculations extremely easy. If you want to
retrieve items for a range of dates, you do not need to parse the key column
to extract the date portion. If you want to look for 'gaps' in the request
numbers for a given day, you do not need to parse the key column. The list
goes on and on.
4) Searches for a specific value are no problem - just allow the user to
enter the value in the encoded format, and convert it to your two column
values. When presenting the value, re-format to the encoded format (which
should really be done in the user interface layer anyway). The users never
need to deal with the actual storage format - and that should (almost) never
be the end-users' concern anyway.
Since you did not post DDL for this table, it is impossible to know, but I
would guess that you might already have a column for RequestDate. In that
case, there really is no good reason for the duplication - just run with
what you have.
"Tim Baur" <trbo20DISREG@.ARDyahoo.com> wrote in message
news:Xns9670A0623995Ctrbo20DISREGARDyaho
o@.207.46.248.16...
> Hey guys, just a quick question for you. I think I know the answer, but I
> would like to get the expert's opinions...
> I have a primary key called RequestID that is to be constructed of the
> year, month, day, and a four-digit sequence number with leading zeros. An
> example of the ninth Request placed today would be:
> 200506090009
> As well as being the primary key, this field will be used in WHERE clauses
> and in joins to several other tables in my schema.
> My question is; should the data type be bigint or char(12)?|||Just a thought,
How about Decimal(12,0)?
That will use 9 bytes though, not really any advantage from a "compact key"
perspective.
Better than having a composite primary key. IMO composite primary key's are
evil.
Just my $0.02.
Richard|||"Jeremy Williams" <jeremydwill@.netscape.net> wrote in
news:OIfXkkTbFHA.2420@.TK2MSFTNGP12.phx.gbl:

> Subject: Re: Primary Key, bigint or char?
> From: "Jeremy Williams" <jeremydwill@.netscape.net>
> Newsgroups: microsoft.public.sqlserver.programming
> Well, I am definitely not an expert, but I definitely have opinions,
> so here goes...
> May I choose super-secret option number three, "None of the Above"?
> How about using a two-column key, consisting of
> RequestDate(smalldatetime) and RequestNumber(smallint)? This would
> provide the following benefits:
> 1) Uses two less bytes than a bigint (bigint = 8 bytes, smalldatetime
> = 4 bytes and smallint = 2 bytes)
> 2) You get a larger set of available numbers for RequestNumber - 10000
> in you setup versus 32000+ in my setup (if you only use the positive
> values). 3) Makes standard types of calculations extremely easy. If
> you want to retrieve items for a range of dates, you do not need to
> parse the key column to extract the date portion. If you want to look
> for 'gaps' in the request numbers for a given day, you do not need to
> parse the key column. The list goes on and on.
> 4) Searches for a specific value are no problem - just allow the user
> to enter the value in the encoded format, and convert it to your two
> column values. When presenting the value, re-format to the encoded
> format (which should really be done in the user interface layer
> anyway). The users never need to deal with the actual storage format -
> and that should (almost) never be the end-users' concern anyway.
> Since you did not post DDL for this table, it is impossible to know,
> but I would guess that you might already have a column for
> RequestDate. In that case, there really is no good reason for the
> duplication - just run with what you have.
>
These are all good points, Jeremy, and your approach was considered.
The way it currently stands:
The request table has an assignment log that will log the creation
date. The point to using a date in the key is because I want the
request number to reset after each day. I would rather the users not be
able to easily figure out how many requests the help desk gets during
the course of a w.
There will *never* be more than 9,999 requests in one day. There
will probably never be more than 10.
Gaps in the sequence are no big deal. I would use Count() to get a
count of records for any particular day or date range.
Composite Keys are not the friendliest to use, especially in a table
as central to the schema as this one. I do use them in other places,
but this particular key serves as a foreign key in six other tables.|||Yeah, I know some developers/DBAs have an unnatural aversion to composite
keys. It seems to "make their teeth itch".
I have never understood the problem myself - it seems much more natural to
use the key information you are already collecting than to make up yet
another key just so you can get it down to one column. As often as not, all
this does is force the developer to join tables unnecessarily when
retrieving data, or use inefficient criteria in their WHERE clauses because
they are parsing the "composite" single column.
As for keeping the user from knowing the number of requests per w, I was
under the impression you would reset the request number each day no matter
how you constructed the key. It would not seem to make a difference whether
you were munging that in with the date in one column, or keeping them
separate - the work is the same. You must have something more going on here
that you have not shown, I guess.
Since your design is already decided on (no composite keys in this
situation), then there really does not seem to be anything compelling
criteria other than storage size to recommend one choice over the other. Go
with the bigint (as others have already said) - it should suit you design
well. Thanks for the dialog!
"Tim Baur" <trbo20DISREG@.ARDyahoo.com> wrote in message
news:Xns96715ECD5928Etrbo20DISREGARDyaho
o@.207.46.248.16...
> "Jeremy Williams" <jeremydwill@.netscape.net> wrote in
> news:OIfXkkTbFHA.2420@.TK2MSFTNGP12.phx.gbl:
>
> These are all good points, Jeremy, and your approach was considered.
> The way it currently stands:
> The request table has an assignment log that will log the creation
> date. The point to using a date in the key is because I want the
> request number to reset after each day. I would rather the users not be
> able to easily figure out how many requests the help desk gets during
> the course of a w.
> There will *never* be more than 9,999 requests in one day. There
> will probably never be more than 10.
> Gaps in the sequence are no big deal. I would use Count() to get a
> count of records for any particular day or date range.
> Composite Keys are not the friendliest to use, especially in a table
> as central to the schema as this one. I do use them in other places,
> but this particular key serves as a foreign key in six other tables.
>|||>> Yeah, I know some developers/DBAs have an unnatural aversion to composite
Actually some level of aversion might be quite natural given the existence
of known issues caused by composite keys that are well documented in
relational literature. Not sure if my teeth itches :-)
Not specific to this case, but in general, simple keys often assist in
formulating simpler relational expressions. Simple keys are often minimal
and always irreducible and therefore partial key dependencies are never an
issue.
And as already mentioned above, there are certain known problems exhibited
by compound keys in referencing table when data may be missing. For
instance, there is no logical choice for a DBMS to decide on whether to
insert/update a row in a referencing table when the values in a subset of
the columns in a multi-column referencing key are missing.
You are right; often developers include additional identifiers assuming they
are a panacea, without understanding the potential benefits or implications
of using an existing key, simple or composite.
Anith|||Thanks for replying, Anith - It is nice to get the input of one of the
actual experts!
Can you guide me to some resources where I can study the composite-key
issues you mentioned further? I have not come across any issues so far, but
I have only been developing in SQL for 10 years or so, so I am sure I have
not seen all there is to see.
My experiences with partial key dependencies typically signified that there
was normalization issues that needed to be worked out - creating an
additional simple key in addition to the composite key would really not have
helped at all. And I freely admit that I do not understand what you mean by:
"For instance, there is no logical choice for a DBMS to decide on whether to
insert/update a row in a referencing table when the values in a subset of
the columns in a multi-column referencing key are missing." If the composite
key is being used in a referencing/referenced table scenario, how does
missing data get involved - a normalized design would require all components
of the composite key to exist, wouldn't it?
I am always looking to expand my knowledge, so please let me know where I
can find out more. Thanks!
"Anith Sen" <anith@.bizdatasolutions.com> wrote in message
news:uYEHCldbFHA.1384@.TK2MSFTNGP09.phx.gbl...
composite
> Actually some level of aversion might be quite natural given the existence
> of known issues caused by composite keys that are well documented in
> relational literature. Not sure if my teeth itches :-)
>
yet
> Not specific to this case, but in general, simple keys often assist in
> formulating simpler relational expressions. Simple keys are often minimal
> and always irreducible and therefore partial key dependencies are never an
> issue.
> And as already mentioned above, there are certain known problems exhibited
> by compound keys in referencing table when data may be missing. For
> instance, there is no logical choice for a DBMS to decide on whether to
> insert/update a row in a referencing table when the values in a subset of
> the columns in a multi-column referencing key are missing.
>
their
> You are right; often developers include additional identifiers assuming
they
> are a panacea, without understanding the potential benefits or
implications
> of using an existing key, simple or composite.
> --
> Anith
>

Primary Key Violation Error in SQL 2005

Hey guys...

I've recently migrated a SQL 2000 db to SQL 2005. There is a table with a defined primary key. In 2000 when I try importing a duplicate record my application would continue and just skip the duplicates. In 2005 I get an error message "Cannot insert duplicate key row in object ... with unique index..." Is there a setting that I can enable/disable to ignore and continue processing when these errors are encountered? I've read a little on "fail package on step failure" but not quite clear on it. Any tips? Thanks alotHey guys...

I've recently migrated a SQL 2000 db to SQL 2005. There is a table with a defined primary key. In 2000 when I try importing a duplicate record my application would continue and just skip the duplicates. In 2005 I get an error message "Cannot insert duplicate key row in object ... with unique index..." Is there a setting that I can enable/disable to ignore and continue processing when these errors are encountered? I've read a little on "fail package on step failure" but not quite clear on it. Any tips? Thanks alot

Thats strange,you should get an error for that in MSSQL 2000 also.|||Can you post DDL (without editing) for the victim table..?

DDL for both tables i.e. table in 2000 & table in 2005.

I used to transfer data, but I didn't face such problem.|||Is it possible that the PK was created with IGNORE_DUP_KEY=ON in 2000, but OFF in 2005?|||Is it possible that the PK was created with IGNORE_DUP_KEY=ON in 2000, but OFF in 2005?

No,that will also give an error of Duplicate key error in your DTS Package execution.|||No,that will also give an error of Duplicate key error in your DTS Package execution.

maybe I am missing something, but I don't see where the kimykimy said they are using DTS for anything. Or are you referring to this statement: "fail package on step failure"?|||maybe I am missing something, but I don't see where the kimykimy said they are using DTS for anything. Or are you referring to this statement: "fail package on step failure"?
exactly ;)|||thanks for your replies. You can ignore my statements on "fail package on step failure." I am not using DTS for the import. Its an insert statement created from a recordset in a vb application.

In SQL 2000 when a duplicate record tries getting inserted it's ignored and moves on to the next record. In SQL 2005 when a duplicate record tries getting inserted I'm getting the "Duplicate Key" error. And the vb code is the same.

Not sure if this helps, but previously this error was resolved by re-restoring the database. Could this be something that was overlooked during the restoration procedure?|||if you are not using DTS, then my previous comment applies. This exact behavior can happen if you have a PK that was created with IGNORE_DUP_KEY=ON (in that case, dupes will be ignored and not inserted).

so check if the PK is IGNORE_DUP_KEY=ON on the 2000 box and IGNORE_DUP_KEY=OFF on the 2005 box.|||I created a new index with the IGNORE_DUP_KEY=ON but when I'm getting an error message "Duplicate Key was ignored" when a dupilcate is encountered.

What I don't understand is I have another table that retreives data in the same method but from a different source without IGNORE_DUP_KEY enabled and it ignores duplicates and continues processing.

Is there a way to ignore this error message from appearing? Thanks|||I created a new index with the IGNORE_DUP_KEY=ON but when I'm getting an error message "Duplicate Key was ignored" when a dupilcate is encountered.

What I don't understand is I have another table that retreives data in the same method but from a different source without IGNORE_DUP_KEY enabled and it ignores duplicates and continues processing.

Is there a way to ignore this error message from appearing? Thanks

Have you created that table in question?If not, then check for any trigger in that existing table...otherwise I think you should get an error ,and thats the way MSSQL works...sql

primary key

hi guys,
i have a doubt. i have a table t1 with columns say c1 and c2. now i want to make the column c1 as my primary key. how to issue a query to do so in sql server 2000 to get executed in sql query analyzer? every time i do with alter cmds, it shows that the column c1 already exists!!!you should be using the ALTER TABLE and ALTER COLUMN commands.

ALTER TABLE MyTable ALTER COLUMN myColumn [int] IDENTITY (1, 1) NOT NULL

Take a look at Books on Line (BOL) some time.

Previous Value Calculation driving me nuts

Hey all,
I've posted my question in the OLAP sql group, but so far no one has
responded, so im hoping you guys can help me out...
My problem is that i am trying to create a value added calculation in a
named query. The calculation i am trying looks like this in algebra
form: (current cost-previous cost)-(current profits-previous profits)
Now the previous cost or previous profits data is based on dates found
in another table (called:tbo.Dates) if that makes any difference
Costs & Profits in table called tbo.Values
If more info is needed, please let me know.
Thanks & Cheers,
Can you provide the DDL (Create Table.. etc) and some sample Data and
what the expected results are?
Barry
daveoram24@.hotmail.com wrote:
> Hey all,
> I've posted my question in the OLAP sql group, but so far no one has
> responded, so im hoping you guys can help me out...
> My problem is that i am trying to create a value added calculation in a
> named query. The calculation i am trying looks like this in algebra
> form: (current cost-previous cost)-(current profits-previous profits)
> Now the previous cost or previous profits data is based on dates found
> in another table (called:tbo.Dates) if that makes any difference
> Costs & Profits in table called tbo.Values
> If more info is needed, please let me know.
> Thanks & Cheers,

Previous Value Calculation driving me nuts

Hey all,
I've posted my question in the OLAP sql group, but so far no one has
responded, so im hoping you guys can help me out...
My problem is that i am trying to create a value added calculation in a
named query. The calculation i am trying looks like this in algebra
form: (current cost-previous cost)-(current profits-previous profits)
Now the previous cost or previous profits data is based on dates found
in another table (called:tbo.Dates) if that makes any difference
Costs & Profits in table called tbo.Values
If more info is needed, please let me know.
Thanks & Cheers,Can you provide the DDL (Create Table.. etc) and some sample Data and
what the expected results are?
Barry
daveoram24@.hotmail.com wrote:
> Hey all,
> I've posted my question in the OLAP sql group, but so far no one has
> responded, so im hoping you guys can help me out...
> My problem is that i am trying to create a value added calculation in a
> named query. The calculation i am trying looks like this in algebra
> form: (current cost-previous cost)-(current profits-previous profits)
> Now the previous cost or previous profits data is based on dates found
> in another table (called:tbo.Dates) if that makes any difference
> Costs & Profits in table called tbo.Values
> If more info is needed, please let me know.
> Thanks & Cheers,