Hi,
Anyone know why the view/ store procedure does not replicate from ServerA to
ServerB?
Thanks,
Kenny
They will be in place if you deploy your subscribers from a backup. If you
create the subscription manually you will need to create them on each node
as well.
Note that if you create a new view or stored procedure they will not be
replicated to each node.
http://www.zetainteractive.com - Shift Happens!
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Kenny" <Kenny@.discussions.microsoft.com> wrote in message
news:5CA78A4E-78B4-488C-BF83-2D4B88A1FCA9@.microsoft.com...
> Hi,
> Anyone know why the view/ store procedure does not replicate from ServerA
> to
> ServerB?
> Thanks,
> Kenny
Showing posts with label servera. Show all posts
Showing posts with label servera. Show all posts
Friday, March 30, 2012
PDFs... Automatically open?
We setting up an intratnet site that is generating PDF output from Reporting
Services 2005.
The WWW Server for the applications is on ServerA
The SQL Server & Reporting Services are on ServerB
From ServerA we are generating a HTTP request to the Reporting Services to
generate the report.
The report is generated as a PDF.
Everything works fine, except that IE always askes if they want to Download
or Open the document.
We simply want it to not ask, and always Open the PDF.
The users will be in a locked Citrix enviornment, so even if we have to stop
it from asking for ANYTHING that is okay as well.
Any ideas?Earl, this is probably because the users have the Confirm open on download
checkbox checked for the PDF filetype. In the Windows Explorer goto Tools,
Folder options, Filetypes, find PDF, click Advanced. Same is true for many
other types like .Doc, Xsl etc.
Ed Richard
"Earl Bonovich" <earl.bonovich...nospam...@.dciinc.org> wrote in message
news:OPlbDBf9FHA.952@.TK2MSFTNGP12.phx.gbl...
> We setting up an intratnet site that is generating PDF output from
> Reporting Services 2005.
> The WWW Server for the applications is on ServerA
> The SQL Server & Reporting Services are on ServerB
> From ServerA we are generating a HTTP request to the Reporting Services to
> generate the report.
> The report is generated as a PDF.
> Everything works fine, except that IE always askes if they want to
> Download or Open the document.
> We simply want it to not ask, and always Open the PDF.
> The users will be in a locked Citrix enviornment, so even if we have to
> stop it from asking for ANYTHING that is okay as well.
> Any ideas?
>
Services 2005.
The WWW Server for the applications is on ServerA
The SQL Server & Reporting Services are on ServerB
From ServerA we are generating a HTTP request to the Reporting Services to
generate the report.
The report is generated as a PDF.
Everything works fine, except that IE always askes if they want to Download
or Open the document.
We simply want it to not ask, and always Open the PDF.
The users will be in a locked Citrix enviornment, so even if we have to stop
it from asking for ANYTHING that is okay as well.
Any ideas?Earl, this is probably because the users have the Confirm open on download
checkbox checked for the PDF filetype. In the Windows Explorer goto Tools,
Folder options, Filetypes, find PDF, click Advanced. Same is true for many
other types like .Doc, Xsl etc.
Ed Richard
"Earl Bonovich" <earl.bonovich...nospam...@.dciinc.org> wrote in message
news:OPlbDBf9FHA.952@.TK2MSFTNGP12.phx.gbl...
> We setting up an intratnet site that is generating PDF output from
> Reporting Services 2005.
> The WWW Server for the applications is on ServerA
> The SQL Server & Reporting Services are on ServerB
> From ServerA we are generating a HTTP request to the Reporting Services to
> generate the report.
> The report is generated as a PDF.
> Everything works fine, except that IE always askes if they want to
> Download or Open the document.
> We simply want it to not ask, and always Open the PDF.
> The users will be in a locked Citrix enviornment, so even if we have to
> stop it from asking for ANYTHING that is okay as well.
> Any ideas?
>
Friday, March 9, 2012
Password question
Morning,
Yesterday I got a call from a developer, telling me that the MSSQL Login
(for a application) that I set up for him on ServerA was not letting him
login. This exact same MSSQL Login was also set up on ServerB and it works
fine. After, a bit of time, of looking into it I stumbled on the problem and
fix. The fix was the password length for the SQL Server login account.
According to BOL, the password can be from 1 to 128 & alpha-numeric. The
password was a 19 alpha-numeric character password. This worked with no
problems on ServerB but failed on ServerA.
ServerB is a Windows 2000 server while ServerA is NT4 SP6.
So, I'm thinking that even though this was a MSSQL login and not a OS login,
the OS layer is playing a role in the authentication process. Does anyone
know if this is so and what are the limitations of NT4 password length?
Thanks for you time,I forgot to add, both are SQL2000 SP3.
"JoeyDBA" <JoeyDBA@.yahoo.com> wrote in message
news:uQErEJmbEHA.716@.TK2MSFTNGP11.phx.gbl...
> Morning,
> Yesterday I got a call from a developer, telling me that the MSSQL Login
> (for a application) that I set up for him on ServerA was not letting him
> login. This exact same MSSQL Login was also set up on ServerB and it works
> fine. After, a bit of time, of looking into it I stumbled on the problem
and
> fix. The fix was the password length for the SQL Server login account.
> According to BOL, the password can be from 1 to 128 & alpha-numeric. The
> password was a 19 alpha-numeric character password. This worked with no
> problems on ServerB but failed on ServerA.
> ServerB is a Windows 2000 server while ServerA is NT4 SP6.
> So, I'm thinking that even though this was a MSSQL login and not a OS
login,
> the OS layer is playing a role in the authentication process. Does anyone
> know if this is so and what are the limitations of NT4 password length?
> Thanks for you time,
>|||If it's a SQL login account we don't interact with the OS.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||As Kevin already pointed out, a SQL Login doesn't interact
with the OS.
One possibility, If the server uses a case-sensitive
collation, then your passwords are case sensitive as well.
-Sue
On Tue, 20 Jul 2004 09:02:59 -0500, "JoeyDBA"
<JoeyDBA@.yahoo.com> wrote:
>Morning,
>Yesterday I got a call from a developer, telling me that the MSSQL Login
>(for a application) that I set up for him on ServerA was not letting him
>login. This exact same MSSQL Login was also set up on ServerB and it works
>fine. After, a bit of time, of looking into it I stumbled on the problem an
d
>fix. The fix was the password length for the SQL Server login account.
>According to BOL, the password can be from 1 to 128 & alpha-numeric. The
>password was a 19 alpha-numeric character password. This worked with no
>problems on ServerB but failed on ServerA.
>ServerB is a Windows 2000 server while ServerA is NT4 SP6.
>So, I'm thinking that even though this was a MSSQL login and not a OS login
,
>the OS layer is playing a role in the authentication process. Does anyone
>know if this is so and what are the limitations of NT4 password length?
>Thanks for you time,
>|||ok - thanks for the feed back. I'll go back and play with it again.
"Kevin McDonnell [MSFT]" <kevmc@.online.microsoft.com> wrote in message
news:8SC7MkobEHA.2924@.cpmsftngxa06.phx.gbl...
> If it's a SQL login account we don't interact with the OS.
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>
Yesterday I got a call from a developer, telling me that the MSSQL Login
(for a application) that I set up for him on ServerA was not letting him
login. This exact same MSSQL Login was also set up on ServerB and it works
fine. After, a bit of time, of looking into it I stumbled on the problem and
fix. The fix was the password length for the SQL Server login account.
According to BOL, the password can be from 1 to 128 & alpha-numeric. The
password was a 19 alpha-numeric character password. This worked with no
problems on ServerB but failed on ServerA.
ServerB is a Windows 2000 server while ServerA is NT4 SP6.
So, I'm thinking that even though this was a MSSQL login and not a OS login,
the OS layer is playing a role in the authentication process. Does anyone
know if this is so and what are the limitations of NT4 password length?
Thanks for you time,I forgot to add, both are SQL2000 SP3.
"JoeyDBA" <JoeyDBA@.yahoo.com> wrote in message
news:uQErEJmbEHA.716@.TK2MSFTNGP11.phx.gbl...
> Morning,
> Yesterday I got a call from a developer, telling me that the MSSQL Login
> (for a application) that I set up for him on ServerA was not letting him
> login. This exact same MSSQL Login was also set up on ServerB and it works
> fine. After, a bit of time, of looking into it I stumbled on the problem
and
> fix. The fix was the password length for the SQL Server login account.
> According to BOL, the password can be from 1 to 128 & alpha-numeric. The
> password was a 19 alpha-numeric character password. This worked with no
> problems on ServerB but failed on ServerA.
> ServerB is a Windows 2000 server while ServerA is NT4 SP6.
> So, I'm thinking that even though this was a MSSQL login and not a OS
login,
> the OS layer is playing a role in the authentication process. Does anyone
> know if this is so and what are the limitations of NT4 password length?
> Thanks for you time,
>|||If it's a SQL login account we don't interact with the OS.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||As Kevin already pointed out, a SQL Login doesn't interact
with the OS.
One possibility, If the server uses a case-sensitive
collation, then your passwords are case sensitive as well.
-Sue
On Tue, 20 Jul 2004 09:02:59 -0500, "JoeyDBA"
<JoeyDBA@.yahoo.com> wrote:
>Morning,
>Yesterday I got a call from a developer, telling me that the MSSQL Login
>(for a application) that I set up for him on ServerA was not letting him
>login. This exact same MSSQL Login was also set up on ServerB and it works
>fine. After, a bit of time, of looking into it I stumbled on the problem an
d
>fix. The fix was the password length for the SQL Server login account.
>According to BOL, the password can be from 1 to 128 & alpha-numeric. The
>password was a 19 alpha-numeric character password. This worked with no
>problems on ServerB but failed on ServerA.
>ServerB is a Windows 2000 server while ServerA is NT4 SP6.
>So, I'm thinking that even though this was a MSSQL login and not a OS login
,
>the OS layer is playing a role in the authentication process. Does anyone
>know if this is so and what are the limitations of NT4 password length?
>Thanks for you time,
>|||ok - thanks for the feed back. I'll go back and play with it again.
"Kevin McDonnell [MSFT]" <kevmc@.online.microsoft.com> wrote in message
news:8SC7MkobEHA.2924@.cpmsftngxa06.phx.gbl...
> If it's a SQL login account we don't interact with the OS.
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>
Subscribe to:
Posts (Atom)