-We are using File version: 2.6.9.616. Version 2.6 final (July 27th, 2009). -We're using run-time version 2.0.50727. -We are using SQL Anywhere for our RDBMS.

We have Image columns in some of our database tables. The database limit for these columns is 2GB, but LLBLGen is capping the length of these fields to 32767. One of these columns is supposed to store a photo of a person and 32K is way too limiting. Opening the table in LLBLGen in edit mode doesn't allow you to change the length of the field and LLBLGen converts the Image column to a byte array in .net. How can I increase the limit on this field?

Thanks in advance!

Regards,

Peter

Which version of Sql Anywhere are you using ?

Matt

If you run the following query on your iAnywhere database:

select tc.*, d.domain_name, d.[precision], r.remarks from systabcol tc
inner join sysdomain d on tc.domain_id = d.domain_id left join sysremark r on tc.object_id = r.object_id
where table_id = 
(
    select table_id from systab where table_name =?
    and creator = 
    (
        select user_id from sysuser where user_name='<schemaname>'
    )
)

and replace the '?' with the table name with the image field (surrounded by single quotes) and replace <schemaname> with the name of the schema of the table, what is the value in the 'width' column for the Image field? That's the value we store for 'Length'.

Sorry for the delayed response.

My SQL Anywhere version is 11.0.1.2355.

The query is returning 32767 for the column width. So this is purely a sybase problem then? Thanks.

The query is returning 32767 for the column width. So this is purely a sybase problem then?

Indeed looks that way, could you please report this issue to them.

Thanks and Good luck.

pszlachetka wrote:

Sorry for the delayed response.

My SQL Anywhere version is 11.0.1.2355.

The query is returning 32767 for the column width. So this is purely a sybase problem then? Thanks.

Also, try to see if you can define the field with a different length, it might be that if you define it with a different length, it's picked up by sybase?

We submitted a case to Sybase. Here is their response:

I just received news from the engineering team this morning. They confirmed that the results you are seeing were created for compatibility reasons. It seems that older versions of the database server only used a 16-bit signed field for the width column (which support a max value of 32767). In the newer versions of the server, this field retains the same values so that older software can utilize the newer database without compatibility issues.

It appears that it would always be wrong and that the width column is not a reliable indicator of the actual image datatype size.

asowles wrote:

We submitted a case to Sybase. Here is their response:

I just received news from the engineering team this morning. They confirmed that the results you are seeing were created for compatibility reasons. It seems that older versions of the database server only used a 16-bit signed field for the width column (which support a max value of 32767). In the newer versions of the server, this field retains the same values so that older software can utilize the newer database without compatibility issues.

It appears that it would always be wrong and that the width column is not a reliable indicator of the actual image datatype size.

ok so i.o.w.: it's a fixed (e.g. 2gb) size? I need to know that so we can update the driver. I'll check with the docs of the iAnywhere db to see whether one can specify different sizes for images etc., and if not, I'll alter the driver so the size is set to a fixed size (e.g. 2GB)

Could you try the attached driver?

My apologies for taking so long to respond. I forgot to mark it to Notify me of thread replies

Thank you for making the change. We will give that a try. We also did hear back from Sybase. They sent this along:

Hi Allen,

We uncovered a facility that LLBLGen could use better to determine the data type constraints. We provide a stored procedure called sa_describe_query. A "call sa_describe_query('SELECT * FROM <table_name>')" will return the right sizes for each column. The result set provides a width and declared_width field. The declared_width provides the SQLDA or buffer size, and the width field describes the maximum size.

Anyhow, let me know if there's anything else I can help you with. I think I saw you were able to get the case open about UAC issues. Other than that, I'll close the case if I hear nothing else.

I'm not sure if you want to use this, but thought that I would pass it along.

Thanks again for all of your help.

Allen

Thanks Allen. The current driver should give the proper sizes for the columns for the types (as 'image' etc. are types which have only a maximum width, which we set to 2gb now). So implementing the change would have the same effect I think (as other widths / lengths are ok). If further problems arise, we'll change the driver and use this method, as we didn't know about it