I have never found a satisfactory explanation in plain english about the difference among the file, system, and user dsn. Could anyone explain when to use one vs. another using practical examples? I have no trouble creating them, I just don't really know which is the correct one in a given situation. <p>Often I simply use DSNless connections. While that would be suitable for web data access, it would not be useful in a situation similar to the one used in the article. <p>Thanks in advance.

> I have never found a satisfactory explanation in plain english about<BR>
> the difference among the file, system, and user dsn. Could anyone<BR>
> explain when to use one vs. another using practical examples? I have<BR>
> no trouble creating them, I just don't really know which is the<BR>
> correct one in a given situation.<BR>
<P>
Here's one explanation from Microsoft in article 213772 :<BR>
------------------------------------------------------------------ <BR>
User DSN<BR>
The User DSN is a data source that is user-specific. A User DSN is stored<BR>
locally but is available only to the user who creates it. User DSNs are not<BR>
used by Microsoft Query. If you use Microsoft Jet, ODBC, or Structured<BR>
Query Language (SQL) commands and bypass Microsoft Query, User DSNs are<BR>
required. User DSNs are stored in the Windows registry under the following<BR>
key:<BR>
<P>
HKEY_CURRENT_USERSoftwareOdbcOdbc.iniOdbc Data sources<BR>
System DSN<BR>
Unlike a User DSN, a System DSN is not user-specific. A System DSN is<BR>
stored locally and is not dedicated to a particular user. Any user who logs<BR>
on to a computer that has permission to access the data source can use a<BR>
System DSN. Some programs, such as Microsoft SQL Server or Microsoft<BR>
Internet Information Server (IIS), require a System DSN. This DSN must be<BR>
created on the server where the program is located. System DSNs are stored<BR>
in the Windows registry under the following key:<BR>
<P>
HKEY_LOCAL_MACHINESoftwareOdbcOdbc.iniOdbc Data sources<BR>
File DSN<BR>
The File DSN is created locally and can be shared with other users. The<BR>
File DSN is file-based, which means that the .dsn file contains all the<BR>
information required to connect to the data source. Note that you must<BR>
install the ODBC driver locally to use a File DSN. Microsoft Query uses<BR>
File DSNs, but Microsoft Jet and ODBC do not use File DSNs.<BR>
--------------------------------------------------------------------------<BR>
<P>
So, one big difference is the visibility to MS Query, visibility to Jet,<BR>
visibility to a user.<BR>
<P>
Bill<BR>
<P>
<P>

Is it possible to create some kind of DSN or something with the same functionality on a network drive for multiple users? Right now I use ADO but I'm just following examples and don't really know what the difference in function is.

Bill Goodland wrote:<BR>
> Is it possible to create some kind of DSN or something with the same<BR>
> functionality on a network drive for multiple users? Right now I use<BR>
> ADO but I'm just following examples and don't really know what the<BR>
> difference in function is.<BR>
<P>
I would imagine that it's possible, but I've never tried it. Seems to me<BR>
it would be more trouble than it's worth, unless we are talking about an<BR>
extraordinary number of users.<BR>
<P>
I believe the only way you could do it would be to make it a File DSN,<BR>
since the other two reside in the registry.<BR>
<P>
Bill<BR>
<P>
<P>

I have created a DSN with a connection type that allows all SQL statements. I can successfully import or link a table into MS Access, but I cannot update the table when it's linked, nor can I export a file to the iSeries from MS Access. <p>I have full authority to the library and files on the iSeries I'm trying to update. <p>I get this message when I have linked a table: <BR>
ODBC - insert on a linked table "libname.filename" failed. <p>I get this message when I try to export a table: <BR>
SQL7008 - "file" in "library" not valid for operation <p>Does anyone know why I get these messages, and what to do about them? <p>Thanks in advance. <BR>
Jörgen

You need to get to the second level text as there's a reason code with more information.<P>
WRKOBJLCK library/file *file to find the QZDASOINIT job when you make the connection, then look in the job log as its running. <BR>
The most likely cause is using the defaults for the connection that expect commitment control and not journaling the file. <p>Trevor

This is a discussion about <B>Microsoft Computing: Accessing iSeries Data with ODBC</b>.<p align='center'><a href=http://www.mcpressonline.com/mc? This e-mail address is being protected from spam bots, you need JavaScript enabled to view it @.6b21cac1>Click here for the article</a>.</p>

You gave me some very interesting and useful information on my problem. I have now managed to fix the issue with updating a linked table from MS Access. <p>Thank you very much! <BR>
Jörgen