Thank you. Here are the results of my tests concerning the dot qualification.
: ?- odbc_import('TABLENAME'('attribute_1','attribute_2'),tablename).
Works! I removed the dot qualification 'ODB.' before TABLENAME.
However,
: ?- tablename(X,Y).
returns
ODBC SYSCALL ERROR (CODE S0002): [Microsoft][SQL Native Client][SQL
Server]Invalid object name 'AFFL'.
ERR - ODBC: Parse error.
I get the same error if I call odbc_sql without the dot qualification:
: ?- odbc_sql([]. 'SELECT attribute_1 from TABLENAME', [ANS]).
Does not work.
I guess that the SQL Native Client requires the dot qualification, but that the
high-level functions do not work with it. I'm stuck.
Thanks,
Hugues
On Mon, Oct 01, 2007 at 10:02:48AM -0400, Robert Pokorny wrote:
> 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
>
>
--
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/
|
