Greetings All!

A couple weeks ago I posted the following question to the RD's ODBC
discussion forum.

<quote>
D3 Linux 7.2.1/RH7.2 or 7.4.2/RHEL4 - most recent patches applied, ODBC C27
in the client WinXP SP2, Visual Studio 2005 Beta 2.

In the VB.NET Project I try to establish a Data Connection by means of .NET
Framework Data Provider for ODBC using system DSN. It will connects well, so
that I will get the list of my tables set up in D3. But as I try to expand a
table I get an error dialog window with "Column 'COLUMN_SIZE' does not
belong to table Columns".

In fact in the D3 SQL account there's no such a field in the system Columns
table. I believe it's might be added as a synonym to 'numeric_precision'
column. Even I tryed to hack that table via UP, and the 'column_size' was
visible by 'isql select ...', but this won't help.

Any ideas?
TIA
Nick
PS. No PDP.NET offerings here, please.
</quote>

Nobody there bothered to reply so far. I'm chasing for any idea down here
now.

Nick

Nick,

Try running the ODBC service in the "foreground". Just run the
D3ODBCSRV -DPV from TCL and see what the query command looks like coming
from .NET

That should show you which column names are being queried for which tables.

Mark Brown

BTW, as has been pointed out before, for non-persistence and killing the
ODBC connection, execute a TCL "off" before closing the ODBC connection.
I've had experience where the ODBC session on Pick would NOT die, even after
the .NET page went away and the browser closed.


"Nikolai Lukin" <nvlukin (AT) gran-service (DOT) ru> wrote

Mark,

Thank you for your suggestion.

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

I will use the suggested command:
odbcsrv -dpv

That's what I have at connection time:

Preparing to Connect:
D3 Machine :'pick0'
D3 User :'dm'
D3 User Pwd :'*NONE*'
D3 Account :'oreh'
D3 Account Pwd:'*NONE*'
Logon successful
SQLTables 0A66F008 (%, %, %, TABLE,SYSTEM TABLE)
Execute 0A66F008( select Table_Qualifier, Table_Owner, Table_Name,
Table_Type, R
emarks from SQL.TABLES where Table_Name is not NULL and Table_Owner =
'oreh'
and Table_Type in ('TABLE','SYSTEMTABLE') order by Table_Type,
Table_Qualifier,
Table_Owner, Table_Name )
[0] Read Index Records ( TABLES Table_Owner )
[1] Extract Columns
[2] Check Condition
[3] Check Condition
[4] Check Condition
19 row(s) selected
Number of Columns = 5
Column Desc. for 5 columns (128 bytes) for stmt 0A66F008.
Fetched 19 rows of 5 columns (882 bytes) for statement 0A66F008.

All my tables will display in the VS's Server Explorer tab properly. Now I
try to expand a table, for instance, 'sltov'. It won't expand, I get
'COLUMN_SIZE' doesn't belong to table Columns message window in VS, and odbc
console will show:

SQLColumns 0A66F008(%, oreh, sltov, %)
Execute 0A66F008( select TABLE_QUALIFIER, TABLE_OWNER, TABLE_NAME,
COLUMN_NAME,
dt.Data_Type DATA_TYPE, dt.Type_Name TYPE_NAME, cl.Numeric_Precision
NUMERIC_PRE
CISION, cl.Numeric_Precision LENGTH, cl.Numeric_Scale SCALE, 10 as RADIX,
cl.IS_
NULLABLE NULLABLE, cl.Column_Remarks REMARKS from SQL.TABLES tb, SQL.COLUMNS
cl,
SQL.DATA_TYPES dt where tb.Table_id=cl.Table_id and
cl.data_type_id=dt.type_i
d and tb.Table_Name = 'sltov' and tb.Table_Owner = 'oreh' and
cl.Column_Name
is not null )
[0] Read Index Records ( TABLES Table_Name Table_Owner )
[1] Extract Columns
[2] Check Condition
[3] Check Condition
[4] Table Absorption
[5] Extract Columns
[6] Loop on Nested Values
[7] Check Condition
[8] Read Record
[9] Extract Columns
12 row(s) selected
Number of Columns = 12
Column Desc. for 12 columns (293 bytes) for stmt 0A66F008.
Fetched 12 rows of 12 columns (1308 bytes) for statement 0A66F008.

It seems to me that this (autogenerated?) query just lacks the 'COLUMN_Size'
field required by VS. Is there any workaround?

Nick

Nick,

Sorry, I don't see anything in the query dialog to indicate that it's even
asking for anything called column_size.

I'm not even sure why it would. SQL uses typed data, so the only things
with lengths are varchar, and they have the field length built into the data
being transfered. Numbers, dates and fields defined as CHAR are all fixed
length.

I can't find any such field defined in anything I have here, and i have
several versions of SQL/SQLDemo available to look thru.

Other commetns embedded for clarity

Mark


"Nikolai Lukin"
belonging to this particular "owner" ie. account.

This is the query to bring over the schema for this table. It's using
aliasing to confuse us as much as possible, but there's nothing wrong so
far.


columns and a number of rows of data, exactly as I'd expect from an Access
query.

Last question stupid as it may sound: Have you tried any other means to
select this data. Access linking, MySql, a dumb Visual Basic project with a
single "data" object? Anything to prove that the problem is with VS and not
with D3/ODBC?

Mark

Mark,

Thanks again for your comprehensive comments. My perception is that D3 ODBC
just doesn't conform to the latest Microsoft specs for ADO.NET 2K5.

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

In fact I used this schema generated by a script in D3 and verified many
times against MSQuery, MS Access linked tables, MS DTS, etc. without a
problem.

I stumbled of VS 2005 because of an attempt to port my working MS DTS 2000
package to the newer Integration services project, which is a replacement
for DTS in MS SQL 2005.

Finally I've given up. It's not my first time when I face D3 failed to
comply with modern mainstream DB technologies

Cheers,
Nick

Nikolai

I just got the same COLUMN_SIZE error message as you did.

Have you had any luck resolving it so far?

I added a post to your question on the RD customer forum, just so RD
should know that other people are having the same problem. According to
Tony, they should at least be aware that numerous people want the issue
resolved. That should at least move it up the priority list. It's not
just one nutcake who has the problem. There are at least 2 nutcakes.

While I understand that RD is not required to worry about beta software
(VS2005 is beta right now), a response would be nice, so we can know
that they are at least looking into it and will advise us further.

Nikolai Lukin wrote:

SH wrote:
And you believed that? Hehe, j/k...

Good attitude!

As you know, I tend to avoid ODBC issues. For this particular issue I
have just a few thoughts:
1) The D3 ODBC client/server is not ADO.NET-aware, this is why most
companies these days have real ADO.NET Data Providers.
2) That D3 ODBC client/server hasn't really been maintained in a
couple years, it's no wonder it's not holding up and I don't expect
things will get any better no matter how many nutcakes complain.
3) If at all possible, try your connectivity outside of VS2005. Can
you make this work as you wish with VS2003? If so then this is a
Microsoft issue, not an RD issue. Of course you'll have a better
chance of getting RD to budge than MS, but if you have an MSDN
subscription then you're entitled to present your issue to MS too, and
FWIW, I've found MS to be very responsive and helpful for things like
this. (They aren't always the "Borg collective" that people make them
out to be.)

T

Nikolai:

I have SQL 2005 Beta 2 Reporting services working nicely with D3 using ODBC
and VS 2005 Beta 2.

Bill

"SH" <shamada (AT) prupipe (DOT) com> wrote

Tony,

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote


No, it's not possible, because the (new) functionality of interest is just
not available in .NET 2003.

Nick

Bill,

"Bill H" <notme (AT) bogus (DOT) com> wrote


It well may work with the Reporting Services, which I didn't try yet, but it
won't in both Visual and BI Studios.

Nick