Yes, it worked. I did exactly what you suggested, and it returned the actual
values that are in the DB. I did the odbc_sql right after the odbc_import that
does not work:
: ?- odbc_import('DB.TABLENAME'('attribute_1',... ), tablename).
Does not work
: ?- odbc_sql([], 'SELECT attribute_1 from DB.TABLENAME', [ANS]).
Does work.
Is it possible to map table to predicate with the lower-level sql interface? I
guess not, since it's low-level. However, that is precisely what interest me:
mapping table to predicate so I can write rules easily, without requiring SQL.
My initial problem is to write inference rules that uses data stored in a
database. The closer I am to the database, the better, I think. That's why XSB
with its table mapping to predicate is interesting. There are other solution,
however, that I've looked into. For example, we have a mapping of the DB schema
to an OWL-DL ontology. Inferring what we need is not easy with OWL.
On another subject, why am I unable to do [odbc_call]. in a program file (.P)?
It says:
[odbc_call loaded]
++Error[XSB/runtime/P]: [Existence (No procedure usermod : odbc_open / 3
exists)] []
Forward Continuation...
I am able to call functions if I import them one at a time with import
odbc_[...] from odbc_call.
I am fairly new to XSB and Prolog, I apologize for my newby questions.
Thank you again,
Hugues
On Mon, Oct 01, 2007 at 09:32:59AM -0400, David Warren wrote:
> 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
--
Hugues Demers
Staff Member
R&D Department
Lockheed Martin Canada
514-340-8310 ext. 8673
-------------------------------------------------------------------------
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/
|
