Board index » delphi » VarChar(>255) in SQL Srvr 7 problem

VarChar(>255) in SQL Srvr 7 problem

D5.01, NT4 w/s, SQL SRVR 7

Insert and Update via stored procs work fine with VarChar(800) (using
TADOStoredProc).

However, Retrieving this data seems to be limited (by Delphi) to 255 chars.

Any ideas on this inconsistency?

TIA,

Martin.

 

Re:VarChar(>255) in SQL Srvr 7 problem


Not as far as I know. VCL limit for string fields is 8192. Result set from
stored procedure can have any size fields.
The only limitation to 255 is the size of output parameters and this is not
Delphi limitation.
If you need larger output parameters, use result set.

--
----------------------
Regards
Robert Cerny
Remove both qwe when replying
email: robert.qwe.ce...@neosys.xrs.qwe.si

No questions via email, unless explicitly invited.

Quote
Martin Moore wrote in message <8bo05t$k...@bornews.borland.com>...
>D5.01, NT4 w/s, SQL SRVR 7

>Insert and Update via stored procs work fine with VarChar(800) (using
>TADOStoredProc).

>However, Retrieving this data seems to be limited (by Delphi) to 255 chars.

>Any ideas on this inconsistency?

>TIA,

>Martin.

Re:VarChar(>255) in SQL Srvr 7 problem


How are you connecting to SQL 7.  If you are using the MDAC then you are
hitting a BDE / ODBC bug that will not allow a VARCHAR to be larger than
255.  To resolve the error, you must switch to ADO.  ADO is the only thing
right now that will support VARCHARs of that size.

Jake

Quote
Robert Cerny <robert.qwe.ce...@neosys.xrs.qwe.si> wrote in message

news:8boe5l.1u.1@neosys.xrs.si...
Quote
> Not as far as I know. VCL limit for string fields is 8192. Result set from
> stored procedure can have any size fields.
> The only limitation to 255 is the size of output parameters and this is
not
> Delphi limitation.
> If you need larger output parameters, use result set.

> --
> ----------------------
> Regards
> Robert Cerny
> Remove both qwe when replying
> email: robert.qwe.ce...@neosys.xrs.qwe.si

> No questions via email, unless explicitly invited.
> Martin Moore wrote in message <8bo05t$k...@bornews.borland.com>...
> >D5.01, NT4 w/s, SQL SRVR 7

> >Insert and Update via stored procs work fine with VarChar(800) (using
> >TADOStoredProc).

> >However, Retrieving this data seems to be limited (by Delphi) to 255
chars.

> >Any ideas on this inconsistency?

> >TIA,

> >Martin.

Re:VarChar(>255) in SQL Srvr 7 problem


Mr. Black.
    Although the jist of what you are saying is correct, the lack of
support for varchar fields >255 characters is not a bug in the BDE, but
is due to the fact that Microsoft is not supporting those field types in
DB-lib. As the BDE is a wrapper to DB-Lib, there is nothing Borland can
do about that. Hence the ADO solution is the only way to access those
field types.

Re:VarChar(>255) in SQL Srvr 7 problem


...or a non BDE ODBC solution as they are supported via the new SQL7 ODBC
driver but the BDE has problems with it.

-Euan

"Bradford C. Miller" <millerb...@spicedhamawayaol.com> wrote in message
news:38DFC5DD.C4C14B0D@spicedhamawayaol.com...

Quote
> Mr. Black.
>     Although the jist of what you are saying is correct, the lack of
> support for varchar fields >255 characters is not a bug in the BDE, but
> is due to the fact that Microsoft is not supporting those field types in
> DB-lib. As the BDE is a wrapper to DB-Lib, there is nothing Borland can
> do about that. Hence the ADO solution is the only way to access those
> field types.

Re:VarChar(>255) in SQL Srvr 7 problem


Of course, I was just stating that the process of hitting the database with
that process is what is breaking his code.

Bradford C. Miller <millerb...@spicedhamawayaol.com> wrote in message
news:38DFC5DD.C4C14B0D@spicedhamawayaol.com...

Quote
> Mr. Black.
>     Although the jist of what you are saying is correct, the lack of
> support for varchar fields >255 characters is not a bug in the BDE, but
> is due to the fact that Microsoft is not supporting those field types in
> DB-lib. As the BDE is a wrapper to DB-Lib, there is nothing Borland can
> do about that. Hence the ADO solution is the only way to access those
> field types.

Other Threads