(As per Martin's request, I am turning my comment into an answer.) I want to add that using long varchar/nvarchar/binary when it is not necessary will have a SERIOUS impact on the client side if your client is a JDBC application using the iAnywhere/SQL Anywhere JDBC driver. The iAnywhere/SA JDBC driver will do its very best to perform wide fetches (i.e. fetch multiple rows at a time) when retrieving result sets from the server. BUT, if any of the columns in the result set are declared long varchar/nvarchar/binary, then the JDBC driver will have no choice but to drop down into single fetch mode due to the fact that the long columns will need to be getdata'd. By the same token, the Remote Data Access layer within SA will also attempt to perform wide fetches from the remote server over ODBC; but once again, if any of the columns are declared long, the Remote Data Access layer will also drop into single fetch mode in order to perform getdata's on the long columns. Hence, from a JDBC client or Remote Data Access standpoint, declaring a column long when it really does not need to be will have fairly significant performance implications. |