Contact Info

Crumbtrail

ActiveXperts.com » Support » ActiveXperts Network Monitor » Online » ADO Database Errors

ADO Database Errors

This is a list of common errors returned by the Microsoft MDAC database object when using an ADO compliant database:

80004005 - data source name not found and no default driver specified

Solution

There are several things that may cause this ODBC error. Many of the possible reasons are listed below.

  • Make sure a Data Source Name (DSN) has been created on both the web server and on the local machine;
  • The DSN may have been set up as a User DSN not a System DSN. This can be resolved by deleting the User DSN and creating a System DSN. Don't forget to delete the User DSN after creating the new System DSN (duplicate DSN names will produce a new ODBC error); Note: Further information about setting up Data Sources Names can be found on page 66 of Using Dreamweaver UltraDev or in the online help system in the section titled "Laying the Groundwork for an Application", under the heading 'Setting up a DSN (ODBC)';
  • The Access file is locked because a lock file (.ldb) exists, even after new System DSN's have been created. The lock file may be due to a DSN of a different name accessing the database. Search in Windows Explorer or Find for *.ldb and delete the yourfilename.ldb file. If another DSN (user or System) exists, you may want to delete it. Be sure to reboot the machine after making these changes;
  • If you are using an Access file, it may have improper permissions. To check the permissions:
    (*) Find the database file in File Explorer;
    (*) Right-click and select properties;
    (*) Select the Security tab and click the Permissions button;
    (*) In the File Permissions dialog, make sure "Everyone" appears in the list box with Full Control.

80004005 - Operation must use an updateable query

Reason

There are several things that may cause this ODBC error. Many of the possible reasons are listed below.

  • The permissions that are set on the directory the database is in. IUSR privileges must be set to "read/write";
  • The permissions on the database itself does not have full read/write privileges in effect;
  • This error can also occur when the database is located outside of the inetpub/wwwroot directory. Though the information is still able to be viewed and searched, it cannot be updated unless it is in the wwwroot directory;
  • The recordset itself was based on a non-updateable query. If you have non-updateable queries within your database (joins are a good example) - this could be the cause. You would actually have to restructure your queries so that they are updateable.
Solution
  • Make sure the permissions for both the directory housing the database and the database itself are set to read/write for the Internet Guest account (IUSR_MACHINE), which is part of the "Everyone" group by default. Also make sure the database is contained somewhere in the wwwroot directory;
  • Test the database by creating a sample page that uses a simple recordset, then add the Insert or Update Record server behavior. If it works, then your original recordset query should be evaluated. The Microsoft article PRB: ASP: "The query is Not Updateable..." Error when Updating provides specific examples of queries that will fail.

80004005 - Microsoft Jet database engine cannot open the file (unknown)

Solution

There are several things that may cause this ODBC error. Many of the possible reasons along with solutions are listed below.

  • This error may occur if the account being used by Internet Information Server (IIS) - usually IUSR - does not have the correct Windows NT permissions for a file based database or for the folder containing the file. Check the permissions on the Internet Information Server account (IUSR) in the NT user manager;
  • Check the permissions on the file and the folder. Ensure that you have the ability to create and/or destroy any temporary files. Temporary files are usually created in the same folder as the database, but the file may also be created in other folders such as /Winnt;
  • If you use a network path to the database (UNC or mapped drive), check the permissions on the share, the file and the folder;
  • Check to make sure that the file and the data source name (DSN) are not marked as Exclusive. Simplify. Use a System DSN that uses a local drive letter. Move the database to the local drive if necessary to test;
  • The error may be caused by a delegation issue. Check the authentication method (Basic versus NTLM) if any. If the connection string uses the Universal Naming Convention (UNC), try using Basic Authentication or an absolute path such as C:\Mydata\Data.mdb. This may happen even if the UNC points to a resource local to the IIS computer;

80004005 - Couldn't use '(unknown)'; file already in use

Reason

There are two common reasons for this error:

  • Windows 2k permissions issue. The account that is accessing the page doesn't have sufficient permissions to lock the database;
  • Time-out value needs to be changed for the Access database DSN.
Solution

To fix the permissions issues, please refer to Microsoft Knowledge Base article 174943 PRB: 80004005 "Couldn't Use '(unknown)'; File Already in Use".

To change the time-out value for the Access database DSN:

  • From the Windows 2000 Start menu, launch the Control Panel by choosing Settings > Control Panel, double click Administrative Tools, then Data Sources (ODBC);
  • Click on the System DSN tab;
  • Highlight the correct DSN and click on the Configure button;
  • Click the Options button, and change the Page Timeout value to 5000.

80004005 - Header Error - The HTTP headers are already written to the client browser

Reason

This error occurs because the Web server has set the client browser using an HTTP header and then tries to reset it using another HTTP header. For example this error can occur when an HTTP header sets the browser to content-type=text/html and a redirection is issued after this. In practice, this occurs when an ASP page is processed that contains HTML tags or any other server-side scripts before a Response.Redirect statement.

Solution

Set the HTTP Headers, such as Redirect statements, prior to sending HTML output. For example, to avoid this error with redirection, buffer or withhold the ASP page during its processing and issue the redirection after processing.

To set buffering on a page level, add code after the @LANGUAGE line on the ASP page which generates the error, as shown below:

<% @LANGUAGE = "VBScript" %>
<% Response.Buffer = True %>
<!-- Other ASP/Clientside scripts or HTML.... -->
<% Response.Redirect %> 

80004005 - Logon Failed() using SQL Server

Reason

This error is generated by SQL server if it does not accept or recognize the logon account and/or password being submitted (if using Standard security) or if there is no Windows NT account to SQL account mapping (when using Integrated security).

Solution

There are several things that may cause this ODBC error. Many of the possible reasons are listed below.

  • If you are using standard security, the account name and password are incorrect. Try the system Admin account and password (UID= "SA" and NULL password). These must be defined on the connection string line. DSNs do not store user names and passwords;
  • If you are using integrated security, check the Windows NT account that is calling the page, and find out what account (if any) it is mapped to;
  • SQL Server does not allow an underscore in a SQL account name;
  • If someone manually mapped the Windows NT IUSR_machinename account to a SQL account of the same name, it fails;
  • Map any account that uses an underscore to an account name on SQL that does not use the underscore.

800a138f - Microsoft JScript runtime error when filtering Recordset with field from another Recordset

Reason

80040e10 - Too few parameters

Reason

This error will occur when the column name used in the query syntax does not exist. Most often this is a typographical error. For more information on this error, go to Microsoft's KnowledgeBase Article: PRB: Error '80040e10' Too Few Parameters. Expected 1: Error Using ADO from ASP Against Access Database.

Solution

Check the column names in your database against your query string to make sure that the parameters are correct.

80040e14 - Syntax error in INSERT INTO statement

Reason

This error typically results from one or more of the following problems with the name of a field, object, or variable within a database.

  • Using a "reserved word" as a name. Most databases have a set of "reserved words" which have meaning to the database engine because they may be used to identify built-in functions or keywords. For example, "date" is a reserved word and cannot be used for column names in the database;
  • Special characters in the name. Examples of special characters include: . / * : ! # & - ?
  • A space in the name;;
  • A column name starts with a numeric character, such as 2products;

The error can also occur when an Input Mask is defined for an object in the database, and the data being inserted does not conform to the mask.

Solution

Avoid using reserved words such as "date", "name", "select", "where" and "level" when specifying field names in your database. Also eliminate spaces and special characters.

A naming convention should be adopted when naming database column values. Consider prepending field names with a prefix. This is a very useful naming technique. When prefixes are used, the possibility of inadvertently using a reserved word is minimized. In fact, this practice can be helpful in other ways; a prefix can actually identify the type of data a field contains.

80040e21 - ODBC error on Insert or Update

Reason

This error indicates the database is not able to handle the update or insert that the page is trying to perform. There are several things that may cause this ODBC error.

  • The page's Server Behavior is attempting to update or insert into a database table's auto number field. The database can't handle an external input into an Autonumber field. When a record is inserted into the database, the autonumber field for the record is defined automatically; therefore, when the update or insert behavior tries to place any data into that field, the behavior fails;
  • The data the Server Behavior is updating or inserting is the wrong type for the database field. For example:
    • Inserting non binary data into a database field that is a yes/no (binary) field;
    • Inserting a string into a database field that has a number data type;
    • Inserting a string into a database field that has a currency or money data type;
    • Inserting an improperly formatted string into a database field that has a date/time data type.
  • Using a "reserved word" as a name. Most databases have a set of "reserved words" which have meaning to the database engine because they may be used to identify built-in functions or keywords. For example, "date" is a reserved word and cannot be used for column names in the database;
  • Special characters in the name. Examples of special characters include: . / * : ! # & - ?
  • A space in the name;
  • A column name starts with a numeric character, such as 2products.

The error can also occur when an Input Mask is defined for an object in the database, and the data being inserted does not conform to the mask.

Solution

To resolve this issue, verify that the data itself is appropriate for the database field's data type. There are actually two things to consider when attempting to ensure the data type matches:

  • The data type you choose while creating the Insert Record or Update Record server behaviors for each submitted form field must be appropriate. For example, if the database field's data type is number, make sure the form field is submitted as integer;
  • Limit visitors from inputting incorrect data, or correct the data after input. This may come into play most frequently with dates.