Best Protocol between linked servers

Hi All,
I'm setting up an environment with two SQLServer2005 instances (on two
different servers).
They're connected thru a linked server (server B to Server A).
Whenever I set the linked server up (in server B), it allows me to choose
between:
1) write the name of the linked server but it must be the same as the real
network name of the server
2) Allow me to choose several parameters but it doesn't use the SQLServer
protocol (faster than any other choice).
As the Stored Procedures (in server B) contains a reference to A's Tables
and it's kinda not possible to change all of them, how do I make the
communication between those server the best ?
Moreover, which protocol priority do I choose in the client network
configuration (Named Pipes is better than TCPIP) ?
Thanks
Igor.Hi Igor,
Take a look at this:
What to use Named Pipes or TCP/IP:
http://www.sqlcommunity.com/Default.aspx?grm2id=55&tabid=77
HTH
Thank you,
Saleem Hakani
HTTP://WWW.SQLCOMMUNITY.COM (World Wide SQL Server Community)
SQLTips, Scripts, Discussions, Blogs, Articles, Radio and a lot of SQL
Server Fun.
"Igor" wrote:
> Hi All,
> I'm setting up an environment with two SQLServer2005 instances (on two
> different servers).
> They're connected thru a linked server (server B to Server A).
> Whenever I set the linked server up (in server B), it allows me to choose
> between:
> 1) write the name of the linked server but it must be the same as the real
> network name of the server
> 2) Allow me to choose several parameters but it doesn't use the SQLServer
> protocol (faster than any other choice).
> As the Stored Procedures (in server B) contains a reference to A's Tables
> and it's kinda not possible to change all of them, how do I make the
> communication between those server the best ?
> Moreover, which protocol priority do I choose in the client network
> configuration (Named Pipes is better than TCPIP) ?
> Thanks
> Igor.

Best practices for concurrent development of DB

Hey guys,
I'm currently setting improving our development process for an app with an
underlying SQL Server DB. We're gonna be two to three people who will be
developing different "regions" of the same database (with region I mean
different tables, queries, sps, etc.)
So far I was the only one working on the DB so I just stuck a backup file of
the DB into source control. But now we'll be two or three people and that
doesn't work anymore.
I think the ideal solution would allow a CVS-style merge of e.g. build and
fill scripts. I'm aware that we might run into conflicts if two people
change the same data but well, I guess there is no perfect solution. Does
anybody have experience with a similar situation?
I also would like to make the thing as automated as possible. In particular
I'm thinking of a mechanism that restores a database from a couple of
scripts and vice versa, something that scripts the whole database as a text
file with one button click (so that source control can do the text-based
merge).
Thanks in advance for your feedback and your ideas.
ChristophLook into what is called a "Unit Test Model." Also, consider modeling your
database base tables with a modeling tool like Computer Associates' ERWin
along with ModelMart. This will allow you to do version control on the
base, i.e., "dbo" schema.
As far as the interface objects: stored procedures, functions, and views,
saving each developer's copies of those objects under their own schema but
against the same base tables allows each of you to do concurrent,
independent work.
Sincerely,
Anthony Thomas
"Christoph Wienands" <christoph.wienands@.siemens.remove.com> wrote in
message news:uTu2bPmhFHA.2156@.TK2MSFTNGP14.phx.gbl...
Hey guys,
I'm currently setting improving our development process for an app with an
underlying SQL Server DB. We're gonna be two to three people who will be
developing different "regions" of the same database (with region I mean
different tables, queries, sps, etc.)
So far I was the only one working on the DB so I just stuck a backup file of
the DB into source control. But now we'll be two or three people and that
doesn't work anymore.
I think the ideal solution would allow a CVS-style merge of e.g. build and
fill scripts. I'm aware that we might run into conflicts if two people
change the same data but well, I guess there is no perfect solution. Does
anybody have experience with a similar situation?
I also would like to make the thing as automated as possible. In particular
I'm thinking of a mechanism that restores a database from a couple of
scripts and vice versa, something that scripts the whole database as a text
file with one button click (so that source control can do the text-based
merge).
Thanks in advance for your feedback and your ideas.
Christoph|||Hey Anthony,
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:%234XqJIphFHA.708@.TK2MSFTNGP10.phx.gbl...
> Look into what is called a "Unit Test Model." Also, consider modeling
> your
> database base tables with a modeling tool like Computer Associates' ERWin
> along with ModelMart. This will allow you to do version control on the
> base, i.e., "dbo" schema.
> As far as the interface objects: stored procedures, functions, and views,
> saving each developer's copies of those objects under their own schema but
> against the same base tables allows each of you to do concurrent,
> independent work.
Thanks for your input. During my research I discovered there are a whole
bunch of tools that support you with that. Here is a link to a page with a
long list of them:
http://www.aspfaq.com/show.asp?id=2209
Some of them integrate with source control, do versioning, allow you to
create upgrade scripts for production databases, etc. Pretty cool stuff :-)
Just for completeness, here the textual list (who knows how long this link
will exist):
AdeptSQL Diff
AGS SQL Scribe
Apex SQLDiff
BMC SQL Programmer
Berryware SQL Matcher
CAST Release Builder
Cobb Systems Data Dictionary
DB Ghost
DBMaestro
Embarcadero DBArtisan
Enhanced ISQL/w
ERwin
Imceda Speed Change Manager
QALite
Quest SQL Impact
Red-Gate SQLCompare (with a companion article at MSSqlServer.com)
SQL Server Comparison Tool
SQL Total Compare
SynchroComp
Total SQL Analyzer
WinSQL
xSQL Object
Regards, Christoph

Best practices for concurrent development of DB

Hey guys,
I'm currently setting improving our development process for an app with an
underlying SQL Server DB. We're gonna be two to three people who will be
developing different "regions" of the same database (with region I mean
different tables, queries, sps, etc.)
So far I was the only one working on the DB so I just stuck a backup file of
the DB into source control. But now we'll be two or three people and that
doesn't work anymore.
I think the ideal solution would allow a CVS-style merge of e.g. build and
fill scripts. I'm aware that we might run into conflicts if two people
change the same data but well, I guess there is no perfect solution. Does
anybody have experience with a similar situation?
I also would like to make the thing as automated as possible. In particular
I'm thinking of a mechanism that restores a database from a couple of
scripts and vice versa, something that scripts the whole database as a text
file with one button click (so that source control can do the text-based
merge).
Thanks in advance for your feedback and your ideas.
Christoph
Look into what is called a "Unit Test Model." Also, consider modeling your
database base tables with a modeling tool like Computer Associates' ERWin
along with ModelMart. This will allow you to do version control on the
base, i.e., "dbo" schema.
As far as the interface objects: stored procedures, functions, and views,
saving each developer's copies of those objects under their own schema but
against the same base tables allows each of you to do concurrent,
independent work.
Sincerely,
Anthony Thomas

"Christoph Wienands" <christoph.wienands@.siemens.remove.com> wrote in
message news:uTu2bPmhFHA.2156@.TK2MSFTNGP14.phx.gbl...
Hey guys,
I'm currently setting improving our development process for an app with an
underlying SQL Server DB. We're gonna be two to three people who will be
developing different "regions" of the same database (with region I mean
different tables, queries, sps, etc.)
So far I was the only one working on the DB so I just stuck a backup file of
the DB into source control. But now we'll be two or three people and that
doesn't work anymore.
I think the ideal solution would allow a CVS-style merge of e.g. build and
fill scripts. I'm aware that we might run into conflicts if two people
change the same data but well, I guess there is no perfect solution. Does
anybody have experience with a similar situation?
I also would like to make the thing as automated as possible. In particular
I'm thinking of a mechanism that restores a database from a couple of
scripts and vice versa, something that scripts the whole database as a text
file with one button click (so that source control can do the text-based
merge).
Thanks in advance for your feedback and your ideas.
Christoph
|||Hey Anthony,
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:%234XqJIphFHA.708@.TK2MSFTNGP10.phx.gbl...
> Look into what is called a "Unit Test Model." Also, consider modeling
> your
> database base tables with a modeling tool like Computer Associates' ERWin
> along with ModelMart. This will allow you to do version control on the
> base, i.e., "dbo" schema.
> As far as the interface objects: stored procedures, functions, and views,
> saving each developer's copies of those objects under their own schema but
> against the same base tables allows each of you to do concurrent,
> independent work.
Thanks for your input. During my research I discovered there are a whole
bunch of tools that support you with that. Here is a link to a page with a
long list of them:
http://www.aspfaq.com/show.asp?id=2209
Some of them integrate with source control, do versioning, allow you to
create upgrade scripts for production databases, etc. Pretty cool stuff :-)
Just for completeness, here the textual list (who knows how long this link
will exist):
AdeptSQL Diff
AGS SQL Scribe
Apex SQLDiff
BMC SQL Programmer
Berryware SQL Matcher
CAST Release Builder
Cobb Systems Data Dictionary
DB Ghost
DBMaestro
Embarcadero DBArtisan
Enhanced ISQL/w
ERwin
Imceda Speed Change Manager
QALite
Quest SQL Impact
Red-Gate SQLCompare (with a companion article at MSSqlServer.com)
SQL Server Comparison Tool
SQL Total Compare
SynchroComp
Total SQL Analyzer
WinSQL
xSQL Object
Regards, Christoph

Best practices for concurrent development of DB

Hey guys,
I'm currently setting improving our development process for an app with an
underlying SQL Server DB. We're gonna be two to three people who will be
developing different "regions" of the same database (with region I mean
different tables, queries, sps, etc.)
So far I was the only one working on the DB so I just stuck a backup file of
the DB into source control. But now we'll be two or three people and that
doesn't work anymore.
I think the ideal solution would allow a CVS-style merge of e.g. build and
fill scripts. I'm aware that we might run into conflicts if two people
change the same data but well, I guess there is no perfect solution. Does
anybody have experience with a similar situation?
I also would like to make the thing as automated as possible. In particular
I'm thinking of a mechanism that restores a database from a couple of
scripts and vice versa, something that scripts the whole database as a text
file with one button click (so that source control can do the text-based
merge).
Thanks in advance for your feedback and your ideas.
ChristophLook into what is called a "Unit Test Model." Also, consider modeling your
database base tables with a modeling tool like Computer Associates' ERWin
along with ModelMart. This will allow you to do version control on the
base, i.e., "dbo" schema.
As far as the interface objects: stored procedures, functions, and views,
saving each developer's copies of those objects under their own schema but
against the same base tables allows each of you to do concurrent,
independent work.
Sincerely,
Anthony Thomas
"Christoph Wienands" <christoph.wienands@.siemens.remove.com> wrote in
message news:uTu2bPmhFHA.2156@.TK2MSFTNGP14.phx.gbl...
Hey guys,
I'm currently setting improving our development process for an app with an
underlying SQL Server DB. We're gonna be two to three people who will be
developing different "regions" of the same database (with region I mean
different tables, queries, sps, etc.)
So far I was the only one working on the DB so I just stuck a backup file of
the DB into source control. But now we'll be two or three people and that
doesn't work anymore.
I think the ideal solution would allow a CVS-style merge of e.g. build and
fill scripts. I'm aware that we might run into conflicts if two people
change the same data but well, I guess there is no perfect solution. Does
anybody have experience with a similar situation?
I also would like to make the thing as automated as possible. In particular
I'm thinking of a mechanism that restores a database from a couple of
scripts and vice versa, something that scripts the whole database as a text
file with one button click (so that source control can do the text-based
merge).
Thanks in advance for your feedback and your ideas.
Christoph|||Hey Anthony,
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:%234XqJIphFHA.708@.TK2MSFTNGP10.phx.gbl...
> Look into what is called a "Unit Test Model." Also, consider modeling
> your
> database base tables with a modeling tool like Computer Associates' ERWin
> along with ModelMart. This will allow you to do version control on the
> base, i.e., "dbo" schema.
> As far as the interface objects: stored procedures, functions, and views,
> saving each developer's copies of those objects under their own schema but
> against the same base tables allows each of you to do concurrent,
> independent work.
Thanks for your input. During my research I discovered there are a whole
bunch of tools that support you with that. Here is a link to a page with a
long list of them:
http://www.aspfaq.com/show.asp?id=2209
Some of them integrate with source control, do versioning, allow you to
create upgrade scripts for production databases, etc. Pretty cool stuff :-)
Just for completeness, here the textual list (who knows how long this link
will exist):
AdeptSQL Diff
AGS SQL Scribe
Apex SQLDiff
BMC SQL Programmer
Berryware SQL Matcher
CAST Release Builder
Cobb Systems Data Dictionary
DB Ghost
DBMaestro
Embarcadero DBArtisan
Enhanced ISQL/w
ERwin
Imceda Speed Change Manager
QALite
Quest SQL Impact
Red-Gate SQLCompare (with a companion article at MSSqlServer.com)
SQL Server Comparison Tool
SQL Total Compare
SynchroComp
Total SQL Analyzer
WinSQL
xSQL Object
Regards, Christoph

Best practice for dbo

When setting up databases for end users, what's the best practice regarding who's the dbo for each individual database - the user itself or a sysadmin?
Does it really have any importance at all who the owner (as defined by 'dbo') is ?I'd strongly recommend leaving sa as dbo, and if need be then making the user a member of the db_owner role if you need that.

-PatP|||Thanks.

The issue was raised when I noticed that for older user databases, someone had assigned a system admin as the dbo by his own, personal user name. When than person then left, and his user was removed, those user databases became orphans.|||You can assign db_ddladmin.

db_ddladmin act same as dbo but it has limited rights comparing db_owner.|||I suspect that Coolberg's problem wasn't one of permission level (they want the user to be equivalent to dbo), but one of ownership (they don't want the login to "own" the database).

There are two issues here that are tightly intertwined, and often confused.

A login is what gives a person access to SQL Server. Logins exist at the server level, and can be either SQL Authenticated or Windows Authenticated. Logins are what "own" a database.

A User is what gives a person permissions inside a SQL Server database. Users exist only inside a database, and are logically tied to exactly one login on the server.

I think that Coolberg wants to keep the ownership of the database limited to an administrative login. I strongly recommend using sa (because you just about can't delete that login), but I agree with the general idea regardless of what login you use.

By using this strategy, you can keep the database ownership limited to an administrative login, but still make any database users memebers of the db_owner role (giving them exactly the same permissions as dbo).

-PatP|||Thanks.
Yes, I'll go for the sa user.
My main goal is to avoid getting orphanized databases when users are leaving in the future.

Best Performance Strip setting RAID

We are running SQL6.5 and plan to upgrade to SQL2000. I'm wondering what's the best stripe size for the RAID 5 configuration. 8,16,32 or 64 kb.
The database is 90% used for read actions. Only during night complete refill of data and write actions only for statistics. Any advise is welcome on this subjectSince SQL server pages are 64K the raid stripe settings must also be set to 64K|||SQL 6.5 uses 2k pages and SQL 2000 uses 8k pages.

The stripe size of your RAID drives does NOT have to follow the page size, however I would use a RAID stripe size >= to my page size.

Best Configuration for a 3 Node SQL 2000 Cluster on Windows 2003?

Ok, I've got the cluster setup and running, but having never done this,
I'm not sure if I'm setting up SQL right... We're trying to migrate
our multitude of SQL Server running on older hardware to the new
cluster, but I want to make sure we don't shoot ourselves in the foot.
Here is what we've got:
Specs:
3 HP BL20P Blade Server (Twin 3.6GHz Xeon, 4GB Ram)
1 HP MSA1000 w/ Twin Fibre Switches (Dual Path Redundancy)
Current Setup:
Windows 2003 Enterprise, 20GB C:, 10GB D: (Pagefile), 37GB E: Data
MSA1000 is currently configured with 4 36GB Arrays (Quorum, 2 for Trans
Logs, and 1 for Backups) and 2 120GB Arrays (Database Data), but there
is about 1.2TB left on the controller for additional space.
Followed all the instructions, Public IPs, Private IPs, etc...
Installed SQL on the first two nodes (SQLCL01 & SQLCL02) and have two
Virtual Servers (Same name, actual server name is longer and unique),
and then two instances, INST1 on SQLCL01, and INST2 on SQLCL02.
SQLCL03 is the failover server which of course is identical to the
first two. We're never expecting to have 2 fail, but we may add a 4th
Server/Node in the future (we have 5 additional slots in our two Blade
Chassis).

>From what I've read you "can" install up to 16 instances into a single
cluster, but obviously I don't know if #1 I should try and install more
than 2 instances, or #2 if I even can. I've tried rerunning the SQL
Setup just to see, and all it lets me do it "modify" the current
install or remove it, it won't let me add another instance.
So... What am I looking at here? Is this the optimum configuration
for now, or can I do more? What about memory? Should I limit each SQL
Server instance to a certain level of RAM, say 3GB? Or possibly 2GB,
incase both the two main servers ever fail and everything gets forced
to the 3rd? These servers will pretty much only be used for SQL,
nothing else, so there isnt' too much worry about applications battling
for memory.
Thanks in advance. I know some of these questions may seem rather
newbish, but I've installed and administered SQL2k before, but never a
cluster... so this is new ground for me and the documentation out
there is not very helpful, most of it refers to SQL2k on Windows 2000,
not Windows Server 2003.
Jon Casimir
Lotsa comments inline.
<kazsmir@.gmail.com> wrote in message
news:1125515891.775160.31810@.z14g2000cwz.googlegro ups.com...
> Ok, I've got the cluster setup and running, but having never done this,
> I'm not sure if I'm setting up SQL right... We're trying to migrate
> our multitude of SQL Server running on older hardware to the new
> cluster, but I want to make sure we don't shoot ourselves in the foot.
> Here is what we've got:
> Specs:
> 3 HP BL20P Blade Server (Twin 3.6GHz Xeon, 4GB Ram)
> 1 HP MSA1000 w/ Twin Fibre Switches (Dual Path Redundancy)
> Current Setup:
> Windows 2003 Enterprise, 20GB C:, 10GB D: (Pagefile), 37GB E: Data
> MSA1000 is currently configured with 4 36GB Arrays (Quorum, 2 for Trans
> Logs, and 1 for Backups) and 2 120GB Arrays (Database Data), but there
> is about 1.2TB left on the controller for additional space.
>
I am not a big fan of blade servers as cluster nodes. Too many single
failure points for what is intended to be a highly available system.
A well-tuned, dedicated SQL server should have minimal need for a paging
file. If you are paging heavily, you have something tuned wrong.
Backups should never be stored on the same host computer or storage array as
the primary data store, even if they are on separate physical disks. Backup
across the net to a file share for immediate use and archive those files to
tape for longer retention periods.

> Followed all the instructions, Public IPs, Private IPs, etc...
> Installed SQL on the first two nodes (SQLCL01 & SQLCL02) and have two
> Virtual Servers (Same name, actual server name is longer and unique),
> and then two instances, INST1 on SQLCL01, and INST2 on SQLCL02.
> SQLCL03 is the failover server which of course is identical to the
> first two. We're never expecting to have 2 fail, but we may add a 4th
> Server/Node in the future (we have 5 additional slots in our two Blade
> Chassis).
This doesn't sound right. You should have each Virtual Server\Instance
combination installed on all nodes on the cluster so you can fail over as
needed. During install time you can select which cluster nodes to install
SQL to. You can set the preferred node order of each Virtual Server later
independently so they start and fail where you choose.
On a multi-node, multi-instance cluster, I usually only worry about
first-order failures. If I have more than one instance go south on me, it
is usually the entire cluster that bombs. If I have one instance with a
problem, somebody competent better be standing in front of it fixing the
problem within 30 minutes. You can adjust memory settings and failover
order at that time.

> cluster, but obviously I don't know if #1 I should try and install more
> than 2 instances, or #2 if I even can. I've tried rerunning the SQL
> Setup just to see, and all it lets me do it "modify" the current
> install or remove it, it won't let me add another instance.
>
SQL won't let you add a new virtual server unless there is at least one
unassigned cluster disk resource to anchor the instance. Whether you
"should" install more instances is another matter. Each instance looks and
acts like a separate server on the network. Generally, multiple instances
in a cluster are used to manage security and performance. In my history, I
find that one instance per node + one spare is an optimal configuration, but
your needs with this server consolidation project may vary.

> So... What am I looking at here? Is this the optimum configuration
> for now, or can I do more? What about memory? Should I limit each SQL
> Server instance to a certain level of RAM, say 3GB? Or possibly 2GB,
> incase both the two main servers ever fail and everything gets forced
> to the 3rd? These servers will pretty much only be used for SQL,
> nothing else, so there isnt' too much worry about applications battling
> for memory.
Since you have paid for Enterprise Edition anyway you should max out the
memory, although your choice of blade servers as hosts may limit that
expansion capability. You will need to consider what happens during a
failover so that you can tolerate "stacking" multiple instances on the same
nost node.

> Thanks in advance. I know some of these questions may seem rather
> newbish, but I've installed and administered SQL2k before, but never a
> cluster... so this is new ground for me and the documentation out
> there is not very helpful, most of it refers to SQL2k on Windows 2000,
> not Windows Server 2003.
Most of the considerations for Windows 2000 clustering apply to Windows
2003, except for some installation gotchas. Unless you are sure something
from Windows 2000 doesn't apply, assume it does.
Now is the best time to ask "dumb" questions. Later, when your "highly
available" database solution that you bet your job on is down is the worst
time.

> Jon Casimir
>
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP

best book on complex DTS packages?

I already know how to use the basics for setting up and running DTS packages in SQL Server 2000. Does anyone have a good recommendation for book(s) that cover advanced DTS topics such as using command line scripts, ETL and so forth to work with complex DTS topics? ThanksThe only one I know about and own is Professional DTS by Wrox books, it was written by guys at Alltel and Encore development which is a BI company.

HTH

BTW: I do reccomend it!

Behavior of SSIS lookup transform on full cache setting with low computer memory

I would like to know what happens when a very large reference data set for a lookup transform with full caching enabled is getting loaded during package execution and the computer memory runs out or is very low.

Does SSIS

a) give an out of memory error of some sort

b) resort to a no caching or partial caching mode

c) maintain the full caching mode but will switch to using the paging file(virtual memory).

I think it will resort to using the page file in which case the benefits of in memory lookups are lost and performance would suffer. If I cannot upgrade the memory or shrink the reference set somehow, i should switch that lookup task to use partial caching or no caching with an indexed lookup table. Would this make sense?

It won't do B unless you explicitly set it. I think it does C as part of the standard Windows memory management, but you might see A too if you are dealing with large data sets.

Your approach would make sense. I'd start by making sure that you are only caching the bare minimum reference set needed, though.

beginner setting up to code in VB

Hey everyone. I'm trying to set up the free microsoft sql 2000 server desktop engine so I can create databases in visual basic using ADO. I would like to do this locally, not over the network or anything. I'm on windows 98. the steps I took are:

1. I downloaded the ms 2000 server desktop engine (msde2000a.exe)
2. Downloaded the .net framework and installed that (version 1.1)
3. Extracted the desktop engine setup to a directory
4. browsed to that directory in DOS prompt and typed 'setup SAPWD="AStrongSAPwd" ... and then it installed
5. opened ODBC Data sources in the control panel
6. in the user DSN tab i highlighted "MQIS" and then pressed 'configure'
7. Pressed 'next' with the default values for all the fields: (name=MQIS, Description=SQL Server' Server=(local) )
8. with the radio button "with sql server authentication.." selected i click on 'client configuration'
9. after i click on that a box comes up saying 'add network library configuration'.

so.. i'm confused on this part.. What should i put for 'server alias' and 'server name'? I want to do this locally. I tried putting my local IP address and the word (local) but after i press 'OK' and then 'Next' (in that previous window that displays the client configuration button) i get an error that says:

Connection failed:
SQLState: '01000'
SQL Server Error: 10061
[Microsoft][ODBC SQL Server Driver][Shared Memory]ConnectionOpen (Connect())
Connection failed:
SQLState: '08001'
SQL Server Error: 17
[Microsoft][ODBC SQL Server Driver][Shared Memory]SQL Server does not exist or access denied

So.. how do I set up my computer to be able to use the engine locally? I have the vbcode I want to work. It consists of creating a database using the "provider=SQLOLEDB..." line. I can submit the code if anyone wants to see. Any help would be greatly appreciated. Thanks!By the way, i DO NOT have SQL Server installed. I was thinking the engine would sort of be like MS Access where you don't actually need Microsoft Access installed to do database manipulation because the Access Jet Engine is built into windows. So I figured installing the SQL Server engine would do the same thing for me. Is this correct? Or is it mandatory that I have SQL Server installed?|||You will definitely need to have SQL Server installed, it won't ship as part of the OS until LongHorn. You can buy the developer edition for about $50, and you get MSDE (the engine alone, like Jet is to MS-Access) included with any of Microsoft's Professional level developer products.

-PatP

Begin Tran ...... Commit Tran

What is the need of BEGIN TRAN...COMMIT TRAN? Also why you are setting Transaction isolation level to SERIALIZABLE?

Quote:

Originally Posted by sajithamol

What is the need of BEGIN TRAN...COMMIT TRAN? Also why you are setting Transaction isolation level to SERIALIZABLE?

Hi ,
Go through the sql online books.|||

Quote:

Originally Posted by sajithamol

What is the need of BEGIN TRAN...COMMIT TRAN? Also why you are setting Transaction isolation level to SERIALIZABLE?

Refer
http://msdn2.microsoft.com/en-us/li...83(SQL.80).aspx
http://msdn2.microsoft.com/en-us/library/ms173763.aspx
http://www.mssqlcity.com/Articles/General/TIL.htm|||

Quote:

Originally Posted by sajithamol

What is the need of BEGIN TRAN...COMMIT TRAN? Also why you are setting Transaction isolation level to SERIALIZABLE?

simple to roll back the qry process done