Basic business rules question

How do you represent business rules in SQL Server? I need the database to return an error to a .net app if a business rule fails.

Thank you! :)

I'm not sure if this is what you mean, but you can use constraints (like CHECK CONSTRAINTS and foreign key constraints) and triggers to enforce business rules.|||Thanks. Yes, I mean something that allows me to create an elaborate procedure to verify compliance with a business rule. Are triggers the only way? I've heard negative things about triggers.|||If you can use constraints then you should because they're more optimal in performance (I think) - and you can use user-defined functions in the constraints to have fairly complex logic. But if not (because the rules are elaborate) I don't see what's wrong with triggers - they are a standard way of enforcing business rules. What negative things did you hear?|||Thanks, mostafae. I can't remember specifically what I heard; I just remember hearing that it's best to avoid them for some reason. But I don't see what the problem is, either. Thanks, again.|||

triggers can cause problems and many people (Self included) recommend against them

1. if the trigger contains much logic, it can hurt performance

2. if you're trouble shooting a slow stored procedure, you will NOT see the trigger code in any query plan. in fact, you wont even know the trigger exists unless you explicitly go look for it. This can cause you to spin your wheels trouble shooting the sproc, when the performance issue is in the trigger all along. (Maintenance nightmare)

3. it's preferable to use constraints

4. IF you must use triggers, be sure to kee them SIMPLE and FAST.

Cheers

|||

1. ... on the other hand, much logic might legitimately be needed for a particularly complex business rule. Is there another way to represent such a rule?

2. How disappointing.

3. Can constraints handle complex business rules that require some process to execute?

4. In what situations might you have no choice but to use Triggers?

:)

|||

well.....

therein lies the question and the topic of debate right...?

You may be forced to use triggers IF for some reason users are accessing your DB without going through a Business Tier.

If users can access the system and circumvent the Application, you could be hosed. If you want to be 100% certain that business logic ALWAYS Fires, regardless of how the DB is accessed, then you may be forced to use triggers (you poor soul).

However, if you're in an environment that allows users to access the DB directly, you have more problems than fiddling with triggers anyway.

The performance problem is not really triggers, it's "business logic" on the Database server. it would be the same thing with containing tons of logic in a sproc. You dont want to have a ton of business logic in a sproc (in my opinion) you want your sprocs to be "Primitive" in nature (Simple CRUD ops). The reason for this is not JUST performance, it's also scalability.

if you take complex logic in a sproc and emulate the same progic in compiled code (C# for example), it's going to perform better due to the fact that it's compiled. Furthermore, it's MUCH easier to scale application servers than DB Servers. In a SQL Cluster you can never have more then 3 boxes, so if your SQL Servers are doing a lot of Business processing you "could" hit the wall quite quickly (think LARGE scale applications like on-line banking, etc). IF you move most or all business logic to business tier (Not just logically, but physically to app servers), you have to ability so scale out as much as you need. You can have as many applications servers as you can afford to purchase.

so, Triggers are not necessarily evil, they are just a trade off in architectural decision making....

I hope this makes sense. Constraints are only going to allow you to implement "Simple rule Logic"

Cheers

|||

Thanks, pdxJaxon. That addresses my concerns, very well, actually.

sql

backups OK in MSDE2000 but won't work in SQLexpress

I'm migrating our app from VS2003/MSDE2000 to VS2005/SQLexpress. Generally no
problems, but the backup of database always fails.
The backup command is
"BACKUP DATABASE icespy5 TO DISK='C:\testbackup'"
I get:
"Cannot open backup device 'C:\testbackup'. Operating system error 5(error not
found). BACKUP DATABASE is terminating abnormally."
The same command works fine with the MSDE database. I have tried other
backup destinations but with no success. I have full admin rights; backup
fails in both debug and release environments.
Any ideas what's wrong?
Evidently permissions are not granted! I can back up to the folder where the
..mdf file is stored, so that will be fine, thanks. However it would be useful
to know how to grant SQL permission to an alternative folder.
Thanks for your help.
"Andrea Montanari" wrote:

> hi,
> quilkin wrote:
> please verify the Windows account the SQLExpress instance is running on has
> been granted adeguate NTFS permissions on the destination path..
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz http://italy.mvps.org
> DbaMgr2k ver 0.21.0 - DbaMgr ver 0.65.0 and further SQL Tools
> -- remove DMO to reply
>
>
|||quilkin,
Try changing SQL service to log in as a Local System instead of a Local or Network Service
Jeff
Check Point Software
================================================== ===
You must be using Outlook Express/Windows Mail or some other type of newsgroup reader to
see and download the file attachment(s). If you are not using a reader, follow
the link below to setup Outlook Express. Click on "Open with newsreader"
under the MS Retail Management System on the right.
http://tinyurl.com/75bgz
================================================== ===
"quilkin" <quilkin@.discussions.microsoft.com> wrote in message news:D58DA277-121E-49AE-96B1-7F91C674DD8D@.microsoft.com...
Evidently permissions are not granted! I can back up to the folder where the
.mdf file is stored, so that will be fine, thanks. However it would be useful
to know how to grant SQL permission to an alternative folder.
Thanks for your help.
"Andrea Montanari" wrote:

> hi,
> quilkin wrote:
> please verify the Windows account the SQLExpress instance is running on has
> been granted adeguate NTFS permissions on the destination path..
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz http://italy.mvps.org
> DbaMgr2k ver 0.21.0 - DbaMgr ver 0.65.0 and further SQL Tools
> -- remove DMO to reply
>
>

Backup With Mirror

Hope this is the right thread,

When you backup with Mirror?

Is that concurrent to those devices and if so, what happens if one fails does the entire backup fail?

Cheers,

Casey

A mirrored backup is basically a read once, write multiple. So, the page is grabbed from the database and then N copies are made within your backup locations. They either all succeed or all fail. So, if you have a failure to one location, you will get a failure on the backup.

Backup Transaction fails.

Hi,
I have taken a back up of a database that was under transactional
replication and was the subscriber. I have restored the backup on to another
server as a stand alone database (no replication what so ever).
I am now trying to truncate the transaction log as its taking a whole lot of
space on the disc and want to shrink the file.
I issue the following statement:
BACKUP LOG <databaseName> WITH NO_LOG
when i issue this statement it comes out with the following error:
The log was not truncated because records at the beginning of the log are
pending replication. Ensure the Log Reader Agent is running or use
sp_repldone to mark transactions as distributed.
Is there any way I can get around this and truncate the log file?
Thanks
Vikram
Vikram,
try:
EXEC sp_repldone @.xactid = NULL, @.xact_segno = NULL, @.numtrans = 0, @.time
= 0, @.reset = 1
then truncate the log.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanks Paul,
I executed that procedure and came up with the following:
Server: Msg 18757, Level 16, State 1, Procedure sp_repldone, Line 1
The database is not published.
Any clues?
Cheers
Vikram
"Paul Ibison" wrote:

> Vikram,
> try:
> EXEC sp_repldone @.xactid = NULL, @.xact_segno = NULL, @.numtrans = 0, @.time
> = 0, @.reset = 1
> then truncate the log.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||One idea I'd try is to publish the database in TR, run the script, truncate,
then drop the publication.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanks very much Paul.
It worked.
thanks a lot.
Cheers
"Paul Ibison" wrote:

> One idea I'd try is to publish the database in TR, run the script, truncate,
> then drop the publication.
> HTH,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
>

Backup to Share with SMO fails, but works to local hard disk

I have a short program (vb.net) which backs up an SQLExpress database. It works fine if the destination is a file on the local drive. However, it always fails if the destination file is a network share or a mapped share. The same program verifies the share is available by trying to read and write a small file before performing the backup.

This is a stripped down version of the code

Dim svr As Server = New Server("Servername")
svr.ConnectionContext.LoginSecure = false
svr.ConnectionContext.Login = TextBoxBULogin.Text
svr.ConnectionContext.Password = TextBoxBUPwd.Text
Dim bkp As Backup = New Backup()
bkp.Action = BackupActionType.Database
bkp.Database = TextBoxBUDatabase.Text
Dim x As New Microsoft.SqlServer.Management.Smo.BackupDeviceItem(destfilepath, DeviceType.File)
bkp.Devices.Add(x)
bkp.SqlBackup(svr)

The exception generated is an SMO.FailedOperationException and reads "System.Data.SqlClient.SqlError: Cannot open backup device 'Z:\v1tbcontacts00.bak'. Device error or device off-line."

Where "Z:\" is a network share. If the backup device string is set to "C:\v1tbcontacts00.bak" the backup succeeds.

Have you tried to use Transact-SQL to backup to the share? In any case you may find it better to back up to the local drive, then copy the backup file using operating system commands to the network share for performance purposes.|||

Henry,

using SQL authentication will make SMO to use the SQL Server Sevice account to authenticate on the network share, so although you might be able to check the network share for existance within your application, the credentials used for this is not used for making the backup on the file share.

Client application (Windows token) --> SQL Server using Windows authentication and connected with Windows Authentication --> SMO uses the Windows credentials of the connected client to access the share

Client application (Windows token) --> SQL Server using Mixed Authentication and connected with SQL Server Authentication --> SMO uses the SQL Server Service account credentials of to access the share

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

|||

The practical solution to my issue is to perform a database backup to the local hard disk and then copy the backup to a share.

Better still. the nugget of information about how authentication works with SMO explains why the problem occured in the first place.

Thanks

Backup to NAS device fails under SQL2k5 X64...

Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after some
non-deterministic period of time) with the error
BackupMedium::ReportIoError: write failure on backup device
'\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735.bak'. Operating
system error 64(The specified network name is no longer available.).
The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried this
on another box with OS patched to max/SQL2K5 at level 3215 with the same
results.
The really weird thing is if I run this exact scenario in the 32-bit
environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's related
to the 64-bit environment. If I point the landing spot for the backup file to
locally attached storage (in a 64-bit VM environment), it works fine.
Has anybody seen this in their 64-bit environment? If so, what did you do to
get around this issue?
PaulIt doesn't sound like a SQL problem. Try copying a large file with xcopy or
explorer and see if the same thing happens.
--
Jason Massie
Web: http://statisticsio.com
RSS: http://feeds.feedburner.com/statisticsio
"psligar" <psligar@.discussions.microsoft.com> wrote in message
news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
> Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after
> some
> non-deterministic period of time) with the error
> BackupMedium::ReportIoError: write failure on backup device
> '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735.bak'. Operating
> system error 64(The specified network name is no longer available.).
> The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried
> this
> on another box with OS patched to max/SQL2K5 at level 3215 with the same
> results.
> The really weird thing is if I run this exact scenario in the 32-bit
> environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's
> related
> to the 64-bit environment. If I point the landing spot for the backup file
> to
> locally attached storage (in a 64-bit VM environment), it works fine.
> Has anybody seen this in their 64-bit environment? If so, what did you do
> to
> get around this issue?
> Paul|||Does the NAS location your trying to write to exist?
'The specified network name is no longer available'
Can you map to the nas location via my computer? If yes to both, then make
sure the ID your using has access to the nas device (read,write, modify,
etc).
I currently have all my SQL2k5 servers backing up to a NAS and I ran into
something similiar and it was due to the Id I was using no longer had access
to the NAS device.
"psligar" <psligar@.discussions.microsoft.com> wrote in message
news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
> Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after
> some
> non-deterministic period of time) with the error
> BackupMedium::ReportIoError: write failure on backup device
> '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735.bak'. Operating
> system error 64(The specified network name is no longer available.).
> The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried
> this
> on another box with OS patched to max/SQL2K5 at level 3215 with the same
> results.
> The really weird thing is if I run this exact scenario in the 32-bit
> environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's
> related
> to the 64-bit environment. If I point the landing spot for the backup file
> to
> locally attached storage (in a 64-bit VM environment), it works fine.
> Has anybody seen this in their 64-bit environment? If so, what did you do
> to
> get around this issue?
> Paul|||Jason:
Thanks for the reply. I should have included that info in my question - that
was our thinking, as well. Our first inclination was to think we had a 64-bit
network driver issue. However, we have copied (via XCOPY) large (~30 GB)
files continuously across the network to the device in question (from the
64-bit VM SQL machine) with no problems.
"Jason Massie" wrote:
> It doesn't sound like a SQL problem. Try copying a large file with xcopy or
> explorer and see if the same thing happens.
> --
> Jason Massie
> Web: http://statisticsio.com
> RSS: http://feeds.feedburner.com/statisticsio
> "psligar" <psligar@.discussions.microsoft.com> wrote in message
> news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
> > Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> > use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after
> > some
> > non-deterministic period of time) with the error
> >
> > BackupMedium::ReportIoError: write failure on backup device
> > '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735.bak'. Operating
> > system error 64(The specified network name is no longer available.).
> >
> > The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried
> > this
> > on another box with OS patched to max/SQL2K5 at level 3215 with the same
> > results.
> >
> > The really weird thing is if I run this exact scenario in the 32-bit
> > environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's
> > related
> > to the 64-bit environment. If I point the landing spot for the backup file
> > to
> > locally attached storage (in a 64-bit VM environment), it works fine.
> >
> > Has anybody seen this in their 64-bit environment? If so, what did you do
> > to
> > get around this issue?
> >
> > Paul
>
>|||Mike:
Thanks for the reply. To answer your question, yes, the location exists - we
are backing up multiple SQL2K 32-bit servers to that location across the
network. Some of those machines are in the ESX environment, as well. I can
map a drive to the network share point on the NAS device from 64-bit VM's in
question. I can copy large files to that share (see my reply to Jason). The
issue in question only surfaces when I try to use the 'BACKUP DATABASE' T-SQL
cmd from within SQL2K5.
In reference to the UID issue you mention, at times, one or more databases
will successfully backup to this device, before it fails on a subsequent DB.
So I'm confident that the UID being used has access to the network share.
NOTE: It's the same UID that is being used by the 32-bit SQL boxes that do
not exhibit this problem.
If I had the hardware availability, I might try setting up a stand alone
64-bit test box (to eliminate the ESX part of this scenario). Unfortunately,
I don't have that option (currently).
Paul
"Mike" wrote:
> Does the NAS location your trying to write to exist?
> 'The specified network name is no longer available'
> Can you map to the nas location via my computer? If yes to both, then make
> sure the ID your using has access to the nas device (read,write, modify,
> etc).
> I currently have all my SQL2k5 servers backing up to a NAS and I ran into
> something similiar and it was due to the Id I was using no longer had access
> to the NAS device.
> "psligar" <psligar@.discussions.microsoft.com> wrote in message
> news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
> > Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> > use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after
> > some
> > non-deterministic period of time) with the error
> >
> > BackupMedium::ReportIoError: write failure on backup device
> > '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735.bak'. Operating
> > system error 64(The specified network name is no longer available.).
> >
> > The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried
> > this
> > on another box with OS patched to max/SQL2K5 at level 3215 with the same
> > results.
> >
> > The really weird thing is if I run this exact scenario in the 32-bit
> > environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's
> > related
> > to the 64-bit environment. If I point the landing spot for the backup file
> > to
> > locally attached storage (in a 64-bit VM environment), it works fine.
> >
> > Has anybody seen this in their 64-bit environment? If so, what did you do
> > to
> > get around this issue?
> >
> > Paul
>
>|||And the saga continues:
I installed the MS tool NetMon version 3.1 'cause I wanted to see what was
going on vis-a-vis the network, and reran the backup job. Lo and behold, it
completed - 5 DB's backed up across the network to a NAS device - a total of
approximately 52 GB. I know that the NetMon tool loaded a packet capture
driver into the network stack - I'm just unsure what other changes it made.
"psligar" wrote:
> Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after some
> non-deterministic period of time) with the error
> BackupMedium::ReportIoError: write failure on backup device
> '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735.bak'. Operating
> system error 64(The specified network name is no longer available.).
> The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried this
> on another box with OS patched to max/SQL2K5 at level 3215 with the same
> results.
> The really weird thing is if I run this exact scenario in the 32-bit
> environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's related
> to the 64-bit environment. If I point the landing spot for the backup file to
> locally attached storage (in a 64-bit VM environment), it works fine.
> Has anybody seen this in their 64-bit environment? If so, what did you do to
> get around this issue?
> Paul

Backup to NAS device fails under SQL2k5 X64...

Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after some
non-deterministic period of time) with the error
BackupMedium::ReportIoError: write failure on backup device
'\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735. bak'. Operating
system error 64(The specified network name is no longer available.).
The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried this
on another box with OS patched to max/SQL2K5 at level 3215 with the same
results.
The really weird thing is if I run this exact scenario in the 32-bit
environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's related
to the 64-bit environment. If I point the landing spot for the backup file to
locally attached storage (in a 64-bit VM environment), it works fine.
Has anybody seen this in their 64-bit environment? If so, what did you do to
get around this issue?
Paul
It doesn't sound like a SQL problem. Try copying a large file with xcopy or
explorer and see if the same thing happens.
Jason Massie
Web: http://statisticsio.com
RSS: http://feeds.feedburner.com/statisticsio
"psligar" <psligar@.discussions.microsoft.com> wrote in message
news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
> Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after
> some
> non-deterministic period of time) with the error
> BackupMedium::ReportIoError: write failure on backup device
> '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735. bak'. Operating
> system error 64(The specified network name is no longer available.).
> The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried
> this
> on another box with OS patched to max/SQL2K5 at level 3215 with the same
> results.
> The really weird thing is if I run this exact scenario in the 32-bit
> environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's
> related
> to the 64-bit environment. If I point the landing spot for the backup file
> to
> locally attached storage (in a 64-bit VM environment), it works fine.
> Has anybody seen this in their 64-bit environment? If so, what did you do
> to
> get around this issue?
> Paul
|||Does the NAS location your trying to write to exist?
'The specified network name is no longer available'
Can you map to the nas location via my computer? If yes to both, then make
sure the ID your using has access to the nas device (read,write, modify,
etc).
I currently have all my SQL2k5 servers backing up to a NAS and I ran into
something similiar and it was due to the Id I was using no longer had access
to the NAS device.
"psligar" <psligar@.discussions.microsoft.com> wrote in message
news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
> Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after
> some
> non-deterministic period of time) with the error
> BackupMedium::ReportIoError: write failure on backup device
> '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735. bak'. Operating
> system error 64(The specified network name is no longer available.).
> The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried
> this
> on another box with OS patched to max/SQL2K5 at level 3215 with the same
> results.
> The really weird thing is if I run this exact scenario in the 32-bit
> environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's
> related
> to the 64-bit environment. If I point the landing spot for the backup file
> to
> locally attached storage (in a 64-bit VM environment), it works fine.
> Has anybody seen this in their 64-bit environment? If so, what did you do
> to
> get around this issue?
> Paul
|||Jason:
Thanks for the reply. I should have included that info in my question - that
was our thinking, as well. Our first inclination was to think we had a 64-bit
network driver issue. However, we have copied (via XCOPY) large (~30 GB)
files continuously across the network to the device in question (from the
64-bit VM SQL machine) with no problems.
"Jason Massie" wrote:

> It doesn't sound like a SQL problem. Try copying a large file with xcopy or
> explorer and see if the same thing happens.
> --
> Jason Massie
> Web: http://statisticsio.com
> RSS: http://feeds.feedburner.com/statisticsio
> "psligar" <psligar@.discussions.microsoft.com> wrote in message
> news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
>
>
|||Mike:
Thanks for the reply. To answer your question, yes, the location exists - we
are backing up multiple SQL2K 32-bit servers to that location across the
network. Some of those machines are in the ESX environment, as well. I can
map a drive to the network share point on the NAS device from 64-bit VM's in
question. I can copy large files to that share (see my reply to Jason). The
issue in question only surfaces when I try to use the 'BACKUP DATABASE' T-SQL
cmd from within SQL2K5.
In reference to the UID issue you mention, at times, one or more databases
will successfully backup to this device, before it fails on a subsequent DB.
So I'm confident that the UID being used has access to the network share.
NOTE: It's the same UID that is being used by the 32-bit SQL boxes that do
not exhibit this problem.
If I had the hardware availability, I might try setting up a stand alone
64-bit test box (to eliminate the ESX part of this scenario). Unfortunately,
I don't have that option (currently).
Paul
"Mike" wrote:

> Does the NAS location your trying to write to exist?
> 'The specified network name is no longer available'
> Can you map to the nas location via my computer? If yes to both, then make
> sure the ID your using has access to the nas device (read,write, modify,
> etc).
> I currently have all my SQL2k5 servers backing up to a NAS and I ran into
> something similiar and it was due to the Id I was using no longer had access
> to the NAS device.
> "psligar" <psligar@.discussions.microsoft.com> wrote in message
> news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
>
>
|||And the saga continues:
I installed the MS tool NetMon version 3.1 'cause I wanted to see what was
going on vis-a-vis the network, and reran the backup job. Lo and behold, it
completed - 5 DB's backed up across the network to a NAS device - a total of
approximately 52 GB. I know that the NetMon tool loaded a packet capture
driver into the network stack - I'm just unsure what other changes it made.
"psligar" wrote:

> Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after some
> non-deterministic period of time) with the error
> BackupMedium::ReportIoError: write failure on backup device
> '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735. bak'. Operating
> system error 64(The specified network name is no longer available.).
> The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried this
> on another box with OS patched to max/SQL2K5 at level 3215 with the same
> results.
> The really weird thing is if I run this exact scenario in the 32-bit
> environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's related
> to the 64-bit environment. If I point the landing spot for the backup file to
> locally attached storage (in a 64-bit VM environment), it works fine.
> Has anybody seen this in their 64-bit environment? If so, what did you do to
> get around this issue?
> Paul