Solved

OPENROWSET to text file fails with Msg 7399 Could not find installable ISAM

Posted on 2004-04-07
27
21,920 Views
Last Modified: 2013-11-15
I'm running clustered SQL 2000 SP3 with Jet 4.0 SP8 and ADO 2.8

Within a stored procedure that is scheduled through SQL Agent to run several times per day, the following query runs:

select *
from OpenRowset('MSDASQL', 'Driver={Microsoft Text Driver (*.txt; *.csv)};
DefaultDir=C:\;',
'select * from tacacs.csv')

This works fine for a while, then suddenly stops working, and each call to the stored procedure generates this error:

Msg 7399, Level 16, State 1, Server DPGL-VS-SQL-02,
Procedure sp_TACACSlog2, Line 73
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [Microsoft][ODBC Text
Driver] Could not find installable ISAM.]
OLE DB error trace [OLE/DB Provider 'MSDASQL'
IDBInitialize::Initialize returned 0x80004005:   ].

However, when I stop and restart the SQL Server, the stored procedure works fine.

Does anyone have any ideas about what is going wrong?

The server is using mixed mode security. Both the SQL Server and SQL Agent services run under the same domain account. This account is a member of the Local Administrators group on the server running SQL Server.

This odd thing is that if I stop and restart the SQL Server and SQL Agent services, this job runs fine (i.e. it calls the stored procedure and retrieves the data with no errors) - so it can't be a security or permissions problem.

But after a few hours, it stops working. And once this procedure stops working, any OPENROWSET I try from Query Analyser to any other CSV or DBF files also returns the same error, so it is not the file that is the  problem. It seems that somehow ADO on the server just stops working.

I was using standard ADO (2.7), but decided to install ADO 2.8 to see if it sorts out the problem, but the problem is still happening.

Please, any advice on how to troubleshoot this further would be much appreciated.

Steve
0
Comment
Question by:SteveDom
  • 14
  • 11
27 Comments
 
LVL 13

Expert Comment

by:danblake
Comment Utility
The closest information I could find was: http://support.microsoft.com/default.aspx?scid=kb;en-us;306397&Product=sql

This relates to your error in terms of the context of building your openquery string. Are you sure the query string is correct ?
0
 

Author Comment

by:SteveDom
Comment Utility
Thanks for that link, danblake. It is interesting that the ProviderString parameter needs to be in a different syntax when used in the OPENROWSET command compared with other data access commands.

How, then, do I determine if my connection string is correct?  The stored procedure that uses my connection string to access the text file works absolutely fine for many hours, returning rows.  So can I assume that if it returns rows, it is correct?

So I do not think the problem is with the connection string.  I think there is something happening that stops the ADO from working on my server, and I need to find out what it is.

Steve
0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
Are all your query strings the same, is it possible you have one query string that is stopping the system from working when it is run or does this only happen intermittently ?

Have you setup the schema.ini file to access the .txt files ?
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/Articles/Q149/0/90.asp&NoWebContent=1&NoWebContent=1

I know this link is old, but I have seen problems with openquery where a schema.ini has not been setup when accessing from sql server -> txt file.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcjetschema_ini_file.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/office97/html/workingwithtextfiles.asp

You just need to place the schema.ini files in the root directory of where the actual file is.
0
 

Author Comment

by:SteveDom
Comment Utility
The stored procedure calls OPENROWSET twice (to two CSV files of identical structure) and uses exactly the same query string, connection string, and syntax.

I have not set up SCHEMA.INI files. If the OPENROWSET works without them for hours, I cannot see why it would suddenly fail if they are not present.

OK, the stored procedure has just failed this morning, so I took the opportunity to do some troubleshooting. Here is some things I have tried from a Query Analyser connection to the server in question:

Test 1:
exec master..xp_cmdshell 'type c:\tacacs.csv'

Result was that the contents of the file were displayed, as expected. This shows that the file is not locked open, and SQL certainly has access to open and read it.

Test 2:
select * from OpenRowset('MSDASQL',
'Driver={Microsoft Text Driver (*.txt; *.csv)};DefaultDir=C:\;',
'select * from tacacs.csv')

Result was Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.  
[OLE/DB provider returned message: [Microsoft][ODBC Text Driver] Could not find installable ISAM.]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize returned 0x80004005:   ].

Test 3:
I created a file called TST.CSV and put it on C:\.  The file contents were:

    A,B,C,D
    1,2,3,4

Then I executed the following query
select * from OpenRowset('MSDASQL',
'Driver={Microsoft Text Driver (*.txt; *.csv)};DefaultDir=C:\;',
'select * from tst.csv')

Result was Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.  
[OLE/DB provider returned message: [Microsoft][ODBC Text Driver] Could not find installable ISAM.]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize returned 0x80004005:   ].

Test 4:
select *
from OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'Text;Database=c:\',tst#csv)

Result was Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error.  
[OLE/DB provider returned message: Could not find installable ISAM.]
OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IDBInitialize::Initialize returned 0x80004005:   ].

Test 5:
I created an Excel file C:\tst.xls (saved as version Excel 5.0) containing:

   A,B,C,D
   1,2,3,4

and ran the following:
EXEC sp_addlinkedserver 'ExcelSource','Jet 4.0','Microsoft.Jet.OLEDB.4.0','c:\tst.xls',NULL,'Excel 5.0'
select * from ExcelSource...[Sheet1$]

Results were that the AddLinkedserver succeeded, but the select returned the usual Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error.  
[OLE/DB provider returned message: Could not find installable ISAM.]
OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IDBInitialize::Initialize returned 0x80004005:   ].

To check my tests, I performed Test 3, 4, and 5 on another server, and all worked fine, i.e. they all returned rows from the tst.csv or tst.xls table.

Test 6:
From another server, I attempt to add a linked server to the server experiencing the problem:

EXEC sp_addlinkedserver @server = 'CL2', @srvproduct = '', @provider = 'MSDASQL', @provstr = 'DRIVER={SQL Server};SERVER=DPGL-VS-SQL-02;UID=sa;PWD=sapwd;'
This added OK, but

exec sp_tables_ex CL2

Result was Server: Msg 7399, Level 16, State 1, Procedure sp_tables_ex, Line 20
OLE DB provider 'MSDASQL' reported an error.  
[OLE/DB provider returned message: [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (Connect()).]
[OLE/DB provider returned message: [Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist or access denied.]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize returned 0x80004005:   ].

So it looks like Data Access or ADO or something has stoped working on the server. If I restart the server, all these tests will work again (for a while).  Does anyone have any suggestions of things I can test while the server is still in its 'broken' state?
0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
Have a look here, its the classic problem/scenario that I see about the ISAM/Registry/File fix problems:
http://www.mvps.org/access/bugs/bugs0017.htm
0
 

Author Comment

by:SteveDom
Comment Utility
Thanks for you input.

The article you refer me to does not explain why my problem would work for a number of hours, then suddenly stop, and be fixed by a reboot.  Also, it is discussing a Microsoft Access problem, not a SQL Server problem.  I did try regsvr32 c:\winnt\system32\mstext40.dll (the current version I have) on my SQL Server, and it registered successfully, but the problem continues. Microsoft Access has never been installed on the server in question, so I will not install it as per the article's suggestion.
0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
Microsoft Access has never been installed on the server in question, so I will not install it as per the article's suggestion. -- Neither am I asking you too.

I have seen a number of different sites, all refering to ISAM drive problems (not all Access related) which basically goes to reinstalling registry settings/files and the ISAM again.
http://oldlook.experts-exchange.com:8080/Databases/Microsoft_SQL_Server/Q_20766893.html

Also can you check the permissions for sql-server on the TMP folders ?
http://support.microsoft.com/?id=814398
(It is possible a AD group policy is kicking in removing permissions to this folder -- this would happen N mins/hours after the server has been up !.)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;296711
http://support.microsoft.com/?id=296711
0
 

Author Comment

by:SteveDom
Comment Utility
AD resetting the permissions on the temp folders when it kicks in sounds very plausible. I will test this after the Easter break - it's a little too close to Easter to be treaking Active Directory on a production system (I know, I have no courage!)

Here is another thing of interest I found while following the steps in Q814398.  My SQL Server and SQL Agent services both run under the same domain user account, SQLSVCACC.  Now, when I execute MASTER..XP_CMDSHELL 'ECHO %USERNAME%', I would expect SQLSVCACC to be returned, but it doesn't - it returns the username that the Cluster Service runs under, CLSVCACC! And running MASTER..XP_CMDSHELL 'ECHO %TEMP%' returns C:\DOCUME~1\CLSVCACC\LOCALS~1\Temp.

Interesting...
0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
Also your demonstration of the %TEMP% enviroment variable may be a cluster bug:
MS-KB Article ID: 821270
That makes sense: -- the cluster service is used to manage the cluster and choose which nodes take part in a particular operation....

Have you created/modified all the registery entrys/items for these accounts ?
Article ID: 283811
(This also details how to change the service account names)

Now, do you have enviroment paths for all the other TMP aspects of the system ?.(It looks like the KB Article will have to be followed to the letter a local login if possible, should be easy if you have a RIM Card installed..)
Am I to presume that the C Drive is part of the cluster/san solution in this setup? (It would be interesting if it was not and you were runnning an A-A Cluster.)

Is it an AA Cluster ?




0
 

Author Comment

by:SteveDom
Comment Utility
I have created a C:\TEMP directory on the server and assigned SYSTEM, the Cluster Server account, and the SQL Server service and SQL Agent service accounts full access to it.  I have set the system environment variables TEMP and TMP to point to C:\TEMP, and logged in as each of the above montioned accounts and set their user environment varables TEMP and TMP to C:\TEMP, and rebooted the server.  But the problem is still occurring.

I read those articles regarding the service account logins, and to assure myself all the registry entries etc. are ok, I used Enterprise Manager to change the NT account of both SQL Server and SQL Agent service to another NT Account (mine), took the SQL Cluster Group Offline and back online again, then used Enterprise Manager to change the NT account of both SQL Server and SQL Agent service to the correct account, and took the SQL Cluster Group Offline and back online again. The NT account I use is a member of Domain Admins, which is a member of the Local Administrators group.

I still get the symptoms of MS-KB Article ID: 821270 (xp_cmdshell 'echo %username%' returns the name of the cluster account rather than the SQL account), but I don't see that this is causing the problem - if it was the cause of the problem, then I would be getting the errors every time, not just after several hours of running fine.

I believe the cluster is set up as Active/Passive (I think that's right - the SQL services and disks run on either one node OR the other, not on both nodes at the same time).  SQL is installed on C: of both nodes (not cluster resource disks), and the SQL data and SQL logs are both on Cluster Resource disks.  ALL disks on the two nodes are SAN disks - there are no local hard drives in the servers.

Back to the Active Directory/Group Policy idea: I have tried causing the failure by forcing the group policy on the server by logging into the server with both the SQL account and the cluster account and executing:
     SECEDIT /refreshpolicy machine_policy /enforce
     SECEDIT /refreshpolicy user_policy /enforce
and retrying the stored procedure, but the procedure works fine. It seems to choose to break only when its damn good any ready!

I'm really at a loss.  I know I could use a BULK INSERT query to get the data, but I feel this ISAM error indicates a more serious issue that could effect many other things on the server, and I want to get it resolved.
0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
OK, we've eliminated some of the simple problems that could be causing this issue.

Just a note from what you've last posted...:
What if the file does not exist on both machines ? (And the cluster moves from one machine to another -- hows it going to find the file ?...)
how are you controlling the pickup from drive C (a local file on one of the servers and not the other ...)
select *
from OpenRowset('MSDASQL', 'Driver={Microsoft Text Driver (*.txt; *.csv)};
DefaultDir=C:\;',
'select * from tacacs.csv')

What happens if you use a Common shared drive (between both nodes) to store/retrieve the file from -- this then eliminates a swap-over from one machine to another...

So if you're looking for the file on Drive C on a machine 1, and the failover cluster has switched to machine 2 -- there will be no file to retrieve.
(Does failover occur when the problem happens to the second machine ? )

OPENROWSET to text file fails with Msg 7399 Could not find installable ISAM
--> Are these ISAM drivers installed on both machines in the cluster (and the registry entrys can be found ?..)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;283881
(The Jet drivers / files should be common on both machines -- its a pretty standard component that gets installed)

/*Is the ISAM message, the full error message as returned when a trace is setup on the system, prior to call ?*/
http://support.microsoft.com/default.aspx?scid=kb;en-us;306212&Product=sql2k
/*I'm hoping we can get some further error diags/information on this one.*/

0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
Why not create a linked server to a file-share on the cluster drive (and look for this via a UNC naming convention) so its available to both nodes of the cluster at the same time ?

This way, the call / config information is at least set-up as a central access source, and you'll be able to access multiple files within the share.
For a linked-server example setup:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_8_qd_12_15ma.asp
0
 

Author Comment

by:SteveDom
Comment Utility
The first thing the stored procedure does is to copy the CSV file from another server to C:\, so the file will always be present on C:\, regardless which cluster node is active.  Over the last month or so that I've been looking at this problem, I haven't seen anything in the logs or Cluster Administrator that shows that any resource or group has failed over or gone offline (except when I do it to fix the problem) - its all very well behaved in this regard.

However, it does sound like a sensible idea to place the CSV file on the SQL group's cluster drive, so I have modified the procedure to do that.

I checked the registry keys, and there is a slight difference between the two cluster nodes. The passive node (node A) has a key for HKLM\SOFTWARE\Microsoft\Jet\3.5 and well as HKLM\SOFTWARE\Microsoft\Jet\4.0.  The active node (node B)only has the key for 4.0.  This is interesting, but I don't think this contributes to the problem, because the error occurs on node B. What would be interesting would be to fail the SQL cluster group to the other node, and see if the problem occurs there or not.

Setting up a linked server as you suggested is also a good idea which I will try.
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 
LVL 13

Expert Comment

by:danblake
Comment Utility
What would be interesting would be to fail the SQL cluster group to the other node, and see if the problem occurs there or not.
--> Sounds like a good idea to me...

I want to try and rule out if its one side of the cluster that is causing problems (all the time) or if it is truly an intermittent problem.

Are the node problems always occuring on cluster node B ?


SP3(a) includes MDAC components from 2.71, have you tried using the latest MDAC 2.8 on both sides of the cluster ?
(Microsoft Data Access Components -- containing most of the librarys/etc..)
http://www.microsoft.com/downloads/details.aspx?FamilyID=6c050fe3-c795-4b7d-b037-185d0506396c&DisplayLang=en
(It could be one of the MDACs are corrupt on one side of your cluster-- the only problem is I believe MDAC 2.8 does not install all the drivers, its bit more of a service pack kind of thing...I'm going to have a look for MDAC removal/full reinstall procedures...)
0
 

Author Comment

by:SteveDom
Comment Utility
Danblake,

One of the first things I did was to install Jet 4.0 SP8 and ADO 2.8 on both nodes (see my first post).  

Unfortunately I have run out of time with troubleshooting this - because of the failures, we missed an important event in the report, so I won't risk it failing again. I have replaced the OPENROWSET with BULK INSERT (I am assuming that because bulk insert doesn't use ADO the error will not occur again, but I will post feedback here in a few days)

For those interested, I replaced

insert #import
select *
from OpenRowset('MSDASQL', 'Driver={Microsoft Text Driver (*.txt; *.csv)};
DefaultDir=H:\;',
'select * from tacacs.csv')

with

BULK INSERT #import
   FROM 'H:\tacacs.csv'
   WITH (FIELDTERMINATOR = ',',ROWTERMINATOR = '\n', FIRSTROW = 2)

Thanks for your comments and suggestions.

-Steve
0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
One of the first things I did was to install Jet 4.0 SP8 and ADO 2.8 on both nodes (see my first post).
--> I'm suspecting that you have some corruption, and a manual uninstall/reinstall of these will work (sometimes apps don't always cleanly uninstall and there are some hangups from old components lying around)...
The fact you have Jet 3.5 on one of your servers indicates that there is a definite difference on your cluster setup machines.

I'm just trying to get down to the bottom of the issue.
MDAC uninstalling/reinstalling:
http://support.microsoft.com/default.aspx?scid=kb;en-us;232060

Note -- 3.5 Jet drivers do not support linked server.
0
 

Author Comment

by:SteveDom
Comment Utility
OK, I have been running two versions of the stored procedure since my last post; the original (using OPENROWSET) and one using BULK INSERT.  The version using OPENROWSET has just begun failing, but the BULK INSERT version works fine.

So I have successfully got myself a stable workaround.

I followed the steps in http://support.microsoft.com/default.aspx?scid=kb;en-us;232060 to check that MDAC was working OK, and it all seemed fine.

But while the OPENROWSET command is failing I could try some troubleshooting. I will follow the advice in the previous post and reinstall MDAC on both nodes.  Can anyone suggest any other things I could try to get to the bottom of what might be causing this problem?

0
 

Author Comment

by:SteveDom
Comment Utility
OK, here's the latest: The BULK INSERT version is still working no problem. But the OPENROWSET version is having more problems. I scheduled it to run every hour. For a while, it failed with the same ISAM error described above. But now, the whole stored procedure never returns.

The stored procedure is called via a scheduled job, and Enterprise Manager reports the job as "Executing job  step '1 (call sp)'  If I try to stop the job, this message is reported:

Microsoft SQL-DMO (ODBC SQLState: 42000)
Error 22022: Unable to post notification to SQLServerAgent (reason: MapViewOfFile() returned error 8, 'Not enough storage is available to process this command.')

and the job is still trying to run. It is definitely the OPENROWSET statement which never returns: I tried executing an OPENROWSET from Query Analyser, and it also just sat there, not returning rows and never completing.

0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
I'm still here, I'm going to try and have look into this in a little bit more detail..
0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
Ok, this applies to all O/s in existance -- the MapViewOfFile error -- and is not normally returned.
What is the size of your file ?
What amount of memory does your Active Server have ?
How big is the server ?

Does your performance monitoring of the system show anything ?
A high usage in memory for instance (based upon limitations - 3-4GB Single Block lookups) ?
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx
(This can be worked around with systems : LME)

Lets have a look at some further information on MapViewOfFile():
http://support.microsoft.com/default.aspx?scid=kb;en-us;818894
Does this read to you like there are problems with big files or there is a maximum size possible through this mechanism based upon % of memory available?

If the handle to open the file by using MapViewofFile is not functioning correctly or as we expect it to in this particular case, I'm sure MS PSS may have a fix or be working on something....
(It could be that the alternative is to use Bulk Insert/BCP at this time ?)
http://support.microsoft.com/default.aspx?scid=kb;en-us;221513
Looks like it is an call to the OS: 131896

Do you get any other errors on the Event Log?
http://support.microsoft.com/default.aspx?scid=kb;EN-US;312362

Have you got the lastest version of all your hardware drivers installed ?
0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
Now this is a good read...:
http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx

Given the method with which PCI addresses memory beyond 32 bits, there is a failure mode that is subtle. Any I/O range that "spans" across two 4-GB regions must be treated specially. If not, the address range will be correctly decoded for only one part of the transfer and the remaining part will be transposed to an incorrect memory location. This will corrupt memory and will crash the system, crash the application, or silently corrupt data at that location. Applications cannot prevent this because they are only presented virtual addresses and have no visibility to the physical level. All operating systems that use PAE face this problem, but some do not explicitly prevent this from occurring and instead depend on the device driver to take the correct actions.

Have a further look at the notes:
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx

System manufactures should ensure that only DAC-capable buses are included in any system design intended to support Large Memory capabilities

Do you have a HCL Certified System ?
0
 

Author Comment

by:SteveDom
Comment Utility
The cluster runs on a pair of Dell PowerEdge 2650 (quad Xeon 3GHz, 4GB RAM)
The largest the CSV file has been is 500,000 bytes (less than 1MB)
The are some Browser warnings in the NT System Event Log which seem to occur about every 3 or 4 hours. (EventID: 8021; Description: The browser was unable to retrieve a list of servers from the browser master \\PDC on the network \Device\NetBT_Tcpip_{6E1F9374-8CDE-4AC0-BB5F-1915FB2D705A}. The data is the error code.) The error codes is sometimes 40 00 00 00  and sometimes 35 00 00 00.
0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
That one is easily fixable.. (The last error you have posted/reason why)
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q135/4/04.asp&NoWebContent=1

The PowerEdge is WHC certified for use in a cluster -- good sign...

Have you got the lastest version of all your hardware drivers installed ?
(Once these more obvious things are sorted....)

If none of this works, I believe a call to MS PSS and hearing what they have got to say about this would be worth a call, this thread should give them some info to go on.
0
 
LVL 13

Expert Comment

by:danblake
Comment Utility
Have you tried calling Dell directly and raising the issue to see if they have experienced any similar errors and grabbed beta / pre-final release drivers ?

(If you already have the latest versions..)
0
 

Author Comment

by:SteveDom
Comment Utility
None of the advice posted has solved the problem, so no points should be allocated.

I have run out of time to allocate to solving this problem, so I have replaced the OPENROWSET with a BULK INSERT which is working fine. There is some other odd intermittent behaviour on that server, so we have scheduled to reinstall it at some appropriate time.

I would have preferred to call Microsoft Support and work through this problem with them, but my boss would not authorise the cost - he'd rather me spend 4 hours rebuilding the cluster - go figure!
0
 
LVL 1

Accepted Solution

by:
GhostMod earned 0 total points
Comment Utility
PAQd and 250 points not refunded

GhostMod
CS Moderator
0

Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

This article explains how to reset the password of the sa account on a Microsoft SQL Server.  The steps in this article work in SQL 2005, 2008, 2008 R2, 2012, 2014 and 2016.
The Delta outage: 650 cancelled flights, more than 1200 delayed flights, thousands of frustrated customers, tens of millions of dollars in damages – plus untold reputational damage to one of the world’s most trusted airlines. All due to a catastroph…
Via a live example, show how to set up a backup for SQL Server using a Maintenance Plan and how to schedule the job into SQL Server Agent.
Viewers will learn how to use the UPDATE and DELETE statements to change or remove existing data from their tables. Make a table: Update a specific column given a specific row using the UPDATE statement: Remove a set of values using the DELETE s…

763 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

6 Experts available now in Live!

Get 1:1 Help Now