I saw in David's last comment that the problem might be with the SQL Server
dot qualification of the table name. I seem to remember that I experienced
this same problem a couple of years ago using the higher level interface and
switched to the lower level as David suggested.
Regards,
Bob Pokorny
-----Original Message-----
From: xsb-development-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
[mailto:xsb-development-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx]
On Behalf Of David
Warren
Sent: Monday, October 01, 2007 9:33 AM
To: Hugues Demers
Cc: xsb-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx; David
Warren; Terrance Swift
Subject: Re: [Xsb-development] Table doesn't have attribute
Hugues Demers writes:
> It seems that odbc_open and odbc_import are completing successfully. The
code I
> sent *is* the entire program, with the name of the tables changed for
security
> reasons, although I've kept the case where appropriate.
>
> Again, the program I have is:
>
> :- auto_table.
> :- import odbc_open/3 from odbc_call.
> :- import odbc_import/2 from odbc_call.
> :- import odbc_close/0 from odbc_call.
>
> :- odbc_open('MySource_Name','Username','Password').
> :- odbc_import('DB.TABLENAME'('attribute_1', 'attribute_2'), tablename).
>
> And the answer is:
>
> [program_name loaded]
> ERR - ODBC: Table doesn't have attribute (Table = DB.TABLENAME,Attribute
=
> attribute_1)
>
> yes
>
> : ?-
>
> I'm sorry that I cannot send my database (it's classified). Could it be
that the
> problem is on the database side? Some weird table attribute? A problem
with MS
> SQL Server 2005?
>
> I have been able to successfully execute the above program with another
> database, where the table's names and attributes were different, with
MySQL.
(And 24 attributes shouldn't (in theory) be a problem.)
I guess I would drop down to the lower level ODBC interface, and try
to see if it can access the database at that level.
I would run XSB, and then from the command line, do:
| ?- [odbc_call].
| ?- odbc_open('MySource_Name','Username','Password').
| ?- odbc_sql([],'SELECT attribute_1 FROM DB.TABLENAME',[ANS]).
and see what it does. This should just pass the SELECT query to the
DB and get back the answers.
I do notice that you have the qualified tablename, with DB. in front.
I don't know how this works. After opening a database, I don't use
the qualifier.
You ask:
> Again, if I change the name of the table for something that does not
exists, I
> get the same error message about table attribute. Why does it not give an
error
> about the table not existing?
This is due to the fact that it just looks to see if it has previously
stored (after a retrieval from the DB) the pair (Table,Attribute). If
this fails, it gives that message. So you get the same message for
either one being wrong.
So looking at the code (in lib/odbc_call.P), it seems as though
odbc_get_attr/4 (called from assert_attributes_info1, called from
assert_attributes_inf) is not doing its job.
We have moved to using the lower-level interface (odbc_sql) to
relational databases. We definitely use that interface to SQL
Server. It's possible that the higher-level interface you are using
has never been fully debugged with it. I'll try to see if I can use
it to connect to our SQL Server database and let you know what
happens.
-David
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Xsb-development mailing list
Xsb-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xsb-development
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
|
