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/
|
