Problem with HOST_NAME Function with Linked View

[Neil]

I have an Access 2000 MDB file with a SQL 7 back end. I have a main table
with 50,000 records; and I have a selections table with 50,000 records for
each machine that uses the database (about 25-50). This allows each user to
have their own set of selections.

The selections table has three fields: ID (int), Sel (bit), MachName
(varchar). ID and MachName comprise the primary key.

I have a view that combines the main table and the entries for the
selections table for the current machine (SQL below). The view works fine
when opened in EM and QA. And if I create a pass-through query from my
Access MDB file, the results are displayed fine.

However, if I link the view to the Access MDB file, I get "#Deleted" in
every field of every record (which seems to indicate that the records were
there and then they were gone). However, if I hard-code the machine name
into the same view instead of using HOST_NAME and then relink the view to
the MDB file, the linked view opens fine. Only when I use HOST_NAME as a
parameter in the view is there a problem with it.

Anyone have any idea what's going on here, or have heard of any issues with
HOST_NAME and ODBC linked objects? SQL for the view is below.

Thanks!

Neil

SELECT INVTRY.*, InvtrySelections.Sel, InvtrySelections.MachName
FROM dbo.INVTRY INNER JOIN
dbo.InvtrySelections ON
dbo.INVTRY.ID = dbo.InvtrySelections.ID
WHERE (dbo.InvtrySelections.MachName = HOST_NAME())

 

[Sylvain Lafontaine]

First, you shouldn't crosspost to newsgroups not relevant to your problem.

Second, create a view that will simply select and display the value of
HOST_NAME() and you will you see if there is a problem with it and
SQL-Server 7 and a MDB file.

 

[Erland Sommarskog]

SELECT INVTRY.*, InvtrySelections.Sel, InvtrySelections.MachName
FROM dbo.INVTRY INNER JOIN
dbo.InvtrySelections ON
dbo.INVTRY.ID = dbo.InvtrySelections.ID
WHERE (dbo.InvtrySelections.MachName = HOST_NAME())

Now that I see the entire view, I repeat what I said before: make
MachName nvarchar, and put the clustered index on this column.

 

[Trevor Best]

I have an Access 2000 MDB file with a SQL 7 back end. I have a main table
with 50,000 records; and I have a selections table with 50,000 records for
each machine that uses the database (about 25-50). This allows each user to
have their own set of selections.

The selections table has three fields: ID (int), Sel (bit), MachName
(varchar). ID and MachName comprise the primary key.

I have a view that combines the main table and the entries for the
selections table for the current machine (SQL below). The view works fine
when opened in EM and QA. And if I create a pass-through query from my
Access MDB file, the results are displayed fine.

However, if I link the view to the Access MDB file, I get "#Deleted" in
every field of every record (which seems to indicate that the records were
there and then they were gone). However, if I hard-code the machine name
into the same view instead of using HOST_NAME and then relink the view to
the MDB file, the linked view opens fine. Only when I use HOST_NAME as a
parameter in the view is there a problem with it.

Anyone have any idea what's going on here, or have heard of any issues with
HOST_NAME and ODBC linked objects? SQL for the view is below.

I've not had any problems with Host_name() as a parameter, as the only
records I retrieve are for my particular machine there is very little
point in returning that column so I never ask the server for it as I
know the value already.

A couple of things you need to know about Access and SQL Server, firstly
bit fields should be made NOT NULL and default to 0 as Access interprets
these as Jet Yes/No columns and treats them accordingly so it expects a
value to be there (In Access/Jet, a Yes/No column cannot be null and
defaults to 0). The results otherwise can be unpredictable.

Secondly, if you have any floating point columns in your data (including
datetime as these are stored as floating point numbers) then you most
probably need a timestamp column as floating point errors can cause the
#Deleted condition you describe.

 

[Guest]

Obscure footnote:

any floating point columns in your data (including
datetime as these are stored as floating point numbers)

SQL Server doesn't store datetime as double. Access does,
and the problem arises because of the rounding error in
the conversion between the Access version and the SQL
Server version, even when values are not 'stored' in Access
at all.

(david)

 

[Neil]

First, you shouldn't crosspost to newsgroups not relevant to your problem.

I wasn't aware that I had done that.

Second, create a view that will simply select and display the value of
HOST_NAME() and you will you see if there is a problem with it and
SQL-Server 7 and a MDB file.

Good point. I created a view that returned the value of HOST_NAME(), and it
linked fine into the MDB. I also created a new table, gave it a two-field
PK, and used HOST_NAME() as a parameter for one of the fields in a view.
That view also linked and displayed records fine. (Didn't do a two-table
test, which would be similar to what I'm working with. But it shows that
HOST_NAME() works fine with MDB linked views.)

Neil

 

[Neil]

After I got your note I did go ahead and make MachName nchar, as BOL says
that HOST_NAME() returns that type, and the sample it showed of storing its
return value in a table used an nchar(30) field.

The InvtrySelections table had the PK (ID/MachName) as the clustered index.
I created a second index on MachName alone, and it made it the clustered
index.

With the above two changes, the results were the same. Still getting
"#Deleted".

Neil

 

[Neil]

I've not had any problems with Host_name() as a parameter, as the only
records I retrieve are for my particular machine there is very little
point in returning that column so I never ask the server for it as I know
the value already.

A couple of things you need to know about Access and SQL Server, firstly
bit fields should be made NOT NULL and default to 0 as Access interprets
these as Jet Yes/No columns and treats them accordingly so it expects a
value to be there (In Access/Jet, a Yes/No column cannot be null and
defaults to 0). The results otherwise can be unpredictable.

Yes, the bit field is Not Null and defaults to zero.

Secondly, if you have any floating point columns in your data (including
datetime as these are stored as floating point numbers) then you most
probably need a timestamp column as floating point errors can cause the
#Deleted condition you describe.

I don't have any floating point columns in my table. However, I went ahead
and added a timestamp field anyway. Same results.

Neil

 

[Neil]

Hello, everyone.

I've made some progress with this strange situation. I played around with
different scenarios of the view with HOST_NAME that won't work when linked
to the MDB file, removing most fields, trying just one table, then the
other, and kept getting the "#Deleted" results. However, I found then when I
didn't assign a logical primary key when I linked the view, the results
displayed fine!

That only makes the situation stranger. But there it is.

In another post here I noted that I had created a test table with a
two-field PK, one of which contained the HOST_NAME value, and created a view
which returned records from this test table, with HOST_NAME() as a parameter
for that field. When I linked that view to the MDB file, selecting the two
PK fields as the logical primary key, it worked fine. So it's not all
logical primary keys that it has problems with.

Neil

 

[Sylvain Lafontaine]

One possible cause for seeing things like #deleted is a missing primary key
or Access is not able to determine which field is the primary key.

You have said in your first post that you have defined a composite primary
key on two field. This is quite possibly the source of your problem: you
should try replacing it with a single field primary key. From past
experience, Access seems to have a lot of trouble with linked tables or
views having composite primary keys.

Also, take a look at the following article; in case it might help you:
http://support.microsoft.com/kb/q209123/

 

[Sylvain Lafontaine]

Also, if possible, that a look on the SQL-Server with the Profiler or
activate the ODBC tracing option. This will give you the possibility of
seeing what Access is trying to do.

 

[Neil]

Re. the composite primary key, note that in my test I did create a table
with a composite primary key, to simulate the situation, and it worked fine.
I followed up on that in my more recent post in this thread, which shows
that the situation is now even more bizarre.

Regarding changing to a single field primary key, I do not believe that is
possible. The main table has a single-field primary key (int, identity), and
the other table (which has a one-to-one relationship with the main table)
has a dual primary key -- one field corresponding to the main table's
primary key, and the other containing the machine name. That table has to
have both fields in the primary key.

The resulting view can have a one-field or two-field virtual primary key
when linked in access, depending on whether or not I include the machine
name field in the resultset. Seems to me that it's better to include it and
have a two-field primary key, so that Access can determine the record.

Neil

 

[Neil]

ODBC tracing might show something. Now sure what Profiler would yield, since
SQL Server seems to be returning the records without any problem.

Neil

 

[Sylvain Lafontaine]

It is not a requirement for relationships to be based on primary keys; so
nothing forbid you to a add a new field as the primary key for the other
table and keep the two other fields for your relationship.

Using a machine name as part of an index is also a bad idea: you should
create another table, put these machine names there and use their identity
values for the second table.

 

[Trevor Best]

Obscure footnote:



SQL Server doesn't store datetime as double. Access does,
and the problem arises because of the rounding error in
the conversion between the Access version and the SQL
Server version, even when values are not 'stored' in Access
at all.

Sorry, my bad. It's 2 ints (or Longs in AccessSpeak).

 

[Philipp Stiefel]

But it shows that HOST_NAME() works fine with MDB linked views.

No, it doesn't!

If you link a table or view to a MDB the hostname is saved
in the Connect-Property for that table and will never change.
Even if the MDB is opened on another machine the HOST_NAME()-
Function will return the name of the machine the table or
view was originally linked to the MDB.

Workaround: Give each client a copy of the MDB and check
on each start of the MDB-App if the Connect-Property of
the tables is correct. If not relink all tables and views
on the client using VBA.

Cheers
Phil

 

[Neil]

Thanks for the tip. Still, my point was that the HOST_NAME() function *does*
work with a linked view in an MDB file (albeit with the restriction that you
note) and doesn't cause "#Deleted" to be in the records. So, unless I can
resolve why it's doing that in this case, which machine HOST_NAME() returns
is a moot point.

Neil

 

[Erland Sommarskog]

After I got your note I did go ahead and make MachName nchar, as BOL
says that HOST_NAME() returns that type, and the sample it showed of
storing its return value in a table used an nchar(30) field.

The InvtrySelections table had the PK (ID/MachName) as the clustered
index. I created a second index on MachName alone, and it made it the
clustered index.

With the above two changes, the results were the same. Still getting
"#Deleted".

As I said, I did not really expect that. I more had performance in mind.

But now it occurred to me, that it's a bit of a non-issue for you. To
wit, the rules for implicit conversion are different in SQL 7 and
SQL 2000. The potential performance problem I saw, probably only exists
in SQL 2000. Then again, it's good to be prepared, in case you upgrade
to SQL 2005 one day.

 

[Neil]

You're saying that SQL 2000 performs implicit conversions, but SQL 7
doesn't? That seems like a step backwards for MS. I wish Access didn't
perform implicit conversions.

 

[Erland Sommarskog]

You're saying that SQL 2000 performs implicit conversions, but SQL 7
doesn't? That seems like a step backwards for MS. I wish Access didn't
perform implicit conversions.

That step backwards was taken with SQL 7 from SQL 6.5. A few more implicit
conversions were added in SQL 2005.

Of course, sometimes you do want implicit conversions. It's convenient
to have explicit conversions from character to datetime, or from integer
to bit. But from string to number and numbers to string? That's only bad.

This particular case is about an implicit conversion between varchar
and nvarchar. (or char/nchar), which can occur in both SQL 7 and SQL 2000.
What is different are the rules of what is being converted. In SQL 2000
there is a strict data-type precendence, so a type with low precendence is
always converted to a higher. Thus, a varchar value is converted to
nvarchar, since nvarchar is higher up. I don't know the rules for SQL 7,
as I never worked much with this version, but I know they are different,
and it might be that values are converted rather than columns.