Co-Existing with MSDE

Can SQL Express reside on the same server as MSDE and both run at the same time (different apps)?

I have one app that runs on MSDE and a new to be developed app by a vendor that needs SQL Express.

Thanks

JB

Yes, that is possible. When you start the SQL 2005 Express setup, it will detect the MSDE and ask if you wish to upgrade or install a new instance. Choose a new instance.

You may wish to read in Books Online about the topic: "Instance Naming Page"

Code Samples for external linking to Reports

Hello All,
Are there any code samples which would let me post a URL
link from a classic ASP app to specified Reports on SRS
via URL querystring parameters?
Any thoughts/insight would be greatly appreciated...
TIA,
--Karthiki found ample examples of this in the samples that was an option on installtion
"Karthik" wrote:
> Hello All,
> Are there any code samples which would let me post a URL
> link from a classic ASP app to specified Reports on SRS
> via URL querystring parameters?
> Any thoughts/insight would be greatly appreciated...
> TIA,
> --Karthik
>

Code Level for Deadlock Detection

I've got a VB app that calls an SQL stored procedure that calls
another SQL stored procedure that updates multiple tables. I want
deadlock detection and recovery. Where can it be done?
The inherited code attempts to check for error 1205 inside the inner
sql stored procedure - an error code check after every update
statement. Will that work? I thought the deadlock victim would kill
the entire stored procedure, not just the blocked update statement.
If the inherited code is wrong, will it work to put the deadlock test
in the outer stored procedure? Will the deadlock victim kill only the
inner stored procedure and return error code 1205 to the outer stored
procedure? Or does it kill both the inner and outer stored
procedures?The transaction is rolled back and the entire back is aborted when you are
chosen as the deadlock victim
(http://www.sommarskog.se/error-handling-I.html). If you want to retry the
operation, you'll need to handle the error in your VB code.
Hope this helps.
Dan Guzman
SQL Server MVP
"William Lipp" <w.b.(MyLastNameHere)@.ieee.org> wrote in message
news:t6sv32d0vahsjme8olhjc90l7dnqu1a9gj@.
4ax.com...
> I've got a VB app that calls an SQL stored procedure that calls
> another SQL stored procedure that updates multiple tables. I want
> deadlock detection and recovery. Where can it be done?
> The inherited code attempts to check for error 1205 inside the inner
> sql stored procedure - an error code check after every update
> statement. Will that work? I thought the deadlock victim would kill
> the entire stored procedure, not just the blocked update statement.
> If the inherited code is wrong, will it work to put the deadlock test
> in the outer stored procedure? Will the deadlock victim kill only the
> inner stored procedure and return error code 1205 to the outer stored
> procedure? Or does it kill both the inner and outer stored
> procedures?|||Try testing it.
A deadlock will terminate the connection so there's nothing that can be done
in the stored procedures.
Put the retry in the VB app.
I use an interface class to access the database so it's easy to put code
like this in all calls.
see
http://www.nigelrivett.net/VB/VB6DataAccessLayer.html
"William Lipp" wrote:

> I've got a VB app that calls an SQL stored procedure that calls
> another SQL stored procedure that updates multiple tables. I want
> deadlock detection and recovery. Where can it be done?
> The inherited code attempts to check for error 1205 inside the inner
> sql stored procedure - an error code check after every update
> statement. Will that work? I thought the deadlock victim would kill
> the entire stored procedure, not just the blocked update statement.
> If the inherited code is wrong, will it work to put the deadlock test
> in the outer stored procedure? Will the deadlock victim kill only the
> inner stored procedure and return error code 1205 to the outer stored
> procedure? Or does it kill both the inner and outer stored
> procedures?
>|||William Lipp (w.b.(MyLastNameHere)@.ieee.org) writes:
> The inherited code attempts to check for error 1205 inside the inner
> sql stored procedure - an error code check after every update
> statement. Will that work? I thought the deadlock victim would kill
> the entire stored procedure, not just the blocked update statement.
Up to SQL 2000 this is correct.
In SQL 2005 you can use TRY-CATCH to trap deadlock errors in a stored
procedure. Since you say "error check after every update statement",
it does not sound like TRY-CATCH, and thus that code is not really
working.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||On Sat, 15 Apr 2006 12:23:49 +0000 (UTC), Erland Sommarskog
<esquel@.sommarskog.se> wrote:

>William Lipp writes:
> Erland Sommarskog writes
>In SQL 2005 you can use TRY-CATCH to trap deadlock errors in a stored
>procedure. Since you say "error check after every update statement",
>it does not sound like TRY-CATCH, and thus that code is not really
>working.
Yes, the existing code just checks @.@.error after the insert - I was
pretty sure that wasn't working. I had hoped that the outer stored
procedure could that method to detect deadlocks within the inner
stored procedure. I believe these responses say that won't work
either - that a deadlock victim in the inner stored procedure will
also kill the outer stored procedure, and the only place I can detect
the deadlock victim and reattempt is from the VB code that called the
outer procedure. Have I got that right?|||William Lipp (w.b.(MyLastNameHere)@.ieee.org) writes:
> Yes, the existing code just checks @.@.error after the insert - I was
> pretty sure that wasn't working. I had hoped that the outer stored
> procedure could that method to detect deadlocks within the inner
> stored procedure. I believe these responses say that won't work
> either - that a deadlock victim in the inner stored procedure will
> also kill the outer stored procedure, and the only place I can detect
> the deadlock victim and reattempt is from the VB code that called the
> outer procedure. Have I got that right?
Yes, for SQL 2000 your assumption is entirely accurate. (Well, there is a
trick you can play with linked servers, but it's fairly obscure.)
For SQL 2005, as I said, it is possible to catch the error in a stored
procedure with the new TRY-CATCH construct.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Code - Anyone seen a replication Progress Indicator?

My app is done in c# and controls merge replication programatically.
Does anyone have any info on how to create a progress indicator for
replication?
I know that for the upcoming sql mobile, there are plans to include one
in the data.sqlserverce namespace. But I have to program one for
windows mobile as well as xp.
thoughts?
thanks,
JJ
What about the status event. This gives some indication of progress.
Hilary Cotter
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
"JJ" <joe.jabour@.gmail.com> wrote in message
news:1118151716.660527.200700@.o13g2000cwo.googlegr oups.com...
> My app is done in c# and controls merge replication programatically.
> Does anyone have any info on how to create a progress indicator for
> replication?
> I know that for the upcoming sql mobile, there are plans to include one
> in the data.sqlserverce namespace. But I have to program one for
> windows mobile as well as xp.
> thoughts?
> thanks,
> JJ
>

Clustered Indexes / Primary Key

Hi All,
I am converting an Access app. from .mdb to ODBC link to a SQL Server.
The first thing I have run into is Clustered Indexes not sorted. I have a
small lookup table with 2 fields. From what I was told here by our DBA,
every key has to have a primary key/clustered index. So, the lookup tables
first field is nothing but Category Numbers which are unique and created by
the user. The table has 121 records. The 2nd field is the Category Name.
The Cat. No. is the Primary Key, Clustered, Unique, No-Nulls. The Cat. Name
is indexed non-clustered. When you open the table, it is sorted by the Cat.
Name and not by the Primary Key! Why?
This is not the behavior I'm looking for. Just learning SQL Server.
Don
The only way you are guaranteed any type of sorting is by
using a query and using an order by clause. You don't want
to depend on a clustered index for sorting your data. You
use an order by.
-Sue
On Thu, 11 Aug 2005 07:59:02 -0700, "Donald King"
<DonaldKing@.discussions.microsoft.com> wrote:

>Hi All,
> I am converting an Access app. from .mdb to ODBC link to a SQL Server.
>The first thing I have run into is Clustered Indexes not sorted. I have a
>small lookup table with 2 fields. From what I was told here by our DBA,
>every key has to have a primary key/clustered index. So, the lookup tables
>first field is nothing but Category Numbers which are unique and created by
>the user. The table has 121 records. The 2nd field is the Category Name.
>The Cat. No. is the Primary Key, Clustered, Unique, No-Nulls. The Cat. Name
>is indexed non-clustered. When you open the table, it is sorted by the Cat.
>Name and not by the Primary Key! Why?
>This is not the behavior I'm looking for. Just learning SQL Server.
>Don
|||Sue,
Thanks, I figured out that a Primary key DOES NOT have to be clustered
which I was misinformed by the DBA here. The ORDER BY clause in a query will
execute faster I believe if the field that your ORDER BY clause refers to is
Indexed.
Tks again,
Don
"Sue Hoegemeier" wrote:

> The only way you are guaranteed any type of sorting is by
> using a query and using an order by clause. You don't want
> to depend on a clustered index for sorting your data. You
> use an order by.
> -Sue
> On Thu, 11 Aug 2005 07:59:02 -0700, "Donald King"
> <DonaldKing@.discussions.microsoft.com> wrote:
>
>
|||I think the clustering PK issues hits people because if you
don't have a clustered index on a table and create a PK the
default is for it to be clustered. But it does not mean it
has to be that way - you can specify non-clustered for the
PK. And yes, if you are accessing the data sequentially that
column may be a good candidate for the clustered index. It's
always good to look at the whole picture with the table
though. You get one clustered index so its important to
choose wisely.
-Sue
On Tue, 16 Aug 2005 10:01:02 -0700, "Donald King"
<DonaldKing@.discussions.microsoft.com> wrote:
[vbcol=seagreen]
>Sue,
> Thanks, I figured out that a Primary key DOES NOT have to be clustered
>which I was misinformed by the DBA here. The ORDER BY clause in a query will
>execute faster I believe if the field that your ORDER BY clause refers to is
>Indexed.
>Tks again,
>Don
>--
>"Sue Hoegemeier" wrote:

Clustered Indexes / Primary Key

Hi All,
I am converting an Access app. from .mdb to ODBC link to a SQL Server.
The first thing I have run into is Clustered Indexes not sorted. I have a
small lookup table with 2 fields. From what I was told here by our DBA,
every key has to have a primary key/clustered index. So, the lookup tables
first field is nothing but Category Numbers which are unique and created by
the user. The table has 121 records. The 2nd field is the Category Name.
The Cat. No. is the Primary Key, Clustered, Unique, No-Nulls. The Cat. Name
is indexed non-clustered. When you open the table, it is sorted by the Cat.
Name and not by the Primary Key! Why'
This is not the behavior I'm looking for. Just learning SQL Server.
DonThe only way you are guaranteed any type of sorting is by
using a query and using an order by clause. You don't want
to depend on a clustered index for sorting your data. You
use an order by.
-Sue
On Thu, 11 Aug 2005 07:59:02 -0700, "Donald King"
<DonaldKing@.discussions.microsoft.com> wrote:

>Hi All,
> I am converting an Access app. from .mdb to ODBC link to a SQL Server.
>The first thing I have run into is Clustered Indexes not sorted. I have a
>small lookup table with 2 fields. From what I was told here by our DBA,
>every key has to have a primary key/clustered index. So, the lookup tables
>first field is nothing but Category Numbers which are unique and created by
>the user. The table has 121 records. The 2nd field is the Category Name.
>The Cat. No. is the Primary Key, Clustered, Unique, No-Nulls. The Cat. Nam
e
>is indexed non-clustered. When you open the table, it is sorted by the Cat
.
>Name and not by the Primary Key! Why'
>This is not the behavior I'm looking for. Just learning SQL Server.
>Don|||Sue,
Thanks, I figured out that a Primary key DOES NOT have to be clustered
which I was misinformed by the DBA here. The ORDER BY clause in a query wil
l
execute faster I believe if the field that your ORDER BY clause refers to is
Indexed.
Tks again,
Don
--
"Sue Hoegemeier" wrote:

> The only way you are guaranteed any type of sorting is by
> using a query and using an order by clause. You don't want
> to depend on a clustered index for sorting your data. You
> use an order by.
> -Sue
> On Thu, 11 Aug 2005 07:59:02 -0700, "Donald King"
> <DonaldKing@.discussions.microsoft.com> wrote:
>
>|||I think the clustering PK issues hits people because if you
don't have a clustered index on a table and create a PK the
default is for it to be clustered. But it does not mean it
has to be that way - you can specify non-clustered for the
PK. And yes, if you are accessing the data sequentially that
column may be a good candidate for the clustered index. It's
always good to look at the whole picture with the table
though. You get one clustered index so its important to
choose wisely.
-Sue
On Tue, 16 Aug 2005 10:01:02 -0700, "Donald King"
<DonaldKing@.discussions.microsoft.com> wrote:
[vbcol=seagreen]
>Sue,
> Thanks, I figured out that a Primary key DOES NOT have to be clustered
>which I was misinformed by the DBA here. The ORDER BY clause in a query wi
ll
>execute faster I believe if the field that your ORDER BY clause refers to i
s
>Indexed.
>Tks again,
>Don
>--
>"Sue Hoegemeier" wrote:
>