read varbinary(max)

Hi,
I'm working with visual c++ and usign MFC ( ODBC ) . I have a problem
with varbinary(max) type of sql server 2005 express. I can read a
varbinary (n ) but when i try to read a varbinary(max) fails.
CDBVariant cvarValor;
m_tablaDeConsulta.GetFieldValue ( campo,
cvarValor );
I use this code to read varbinary fields. The only differrence betwen
max a normal varbinary is the precision. When i read a varbinary
precision is 0.
Someone can help me?
thanks.AKS ha escrito:

> Hi,
> I'm working with visual c++ and usign MFC ( ODBC ) . I have a problem
> with varbinary(max) type of sql server 2005 express. I can read a
> varbinary (n ) but when i try to read a varbinary(max) fails.
> CDBVariant cvarValor;
> m_tablaDeConsulta.GetFieldValue ( campo,
> cvarValor );
> I use this code to read varbinary fields. The only differrence betwen
> max a normal varbinary is the precision. When i read a varbinary
> precision is 0.
> Someone can help me?
> thanks.
At least i can read a varbinary. The code
// get data size
void* buffer = malloc ( 1 );
SQLINTEGER tam = 0;
tam = m_tablaDeConsulta.GetData ( m_tablaDeConsulta.m_pDatabase,
m_tablaDeConsulta.m_hstmt, ind+1, SQL_C_BINARY, buffer, 0, SQL_C_BINARY
);
free (buffer );
// alloc data buffer
CDBVariant cvarValor;
buffer = m_tablaDeConsulta.GetDataBuffer( cvarValor, SQL_C_BINARY,
&tam, SQL_C_BINARY, tam);
// read data
m_tablaDeConsulta.GetData ( m_tablaDeConsulta.m_pDatabase,
m_tablaDeConsulta.m_hstmt, ind+1, SQL_C_BINARY, buffer, tam,
SQL_C_BINARY );

Read Only ODBC to SQL SERVER 2005

I have a Login that I setup in SQL Server 2005. The only database roles given to the login are db_datareader and public. On SQL 2000 these permissions are sufficient to allow me to setup a read only ODBC connection using this login and creating an import table in Access. When using the login in SQL 2005 and creating an import table, I am able to edit the underlying data, something I am not able to do with a SQL 2000 ODBC connection. Is there something in SQL 2005 that I am unaware of that would allow this login to modify (update) the table?

Assuming you are using SQL Server Authentication, I'd just double check the roles that account is a member of, and what permissions those roles have on the table in question.

If you are using Windows Authentication, make sure your account is NOT a member of the administrators group on the server. If it is, it automatically becomes part of the Server Administrator's role and can basically do anything.

When I run into these things I often find it's something silly that I overlooked. Having another person look at things for you will often help catch the things you miss.

Good Luck

|||

We have 3 peoople looking at it, one of us has exprience going back to SQL 6.5, but no one can figure it out, lol. We are using SQL Auth and we even tried to deny update rights to the user on the table and take away all grant rights. As soon as we connect to a SQL 2005 table in Access using the ODBC, the user can edit whatever. It is strange because with the exact same permissions in 2000, the user is denied the access and it acts like we expect. In 2005, it is just a free for all. I know it is something silly and we are all going to slap our foreheads when we figure it out

|||

We had to give the user db_denydatawriter permissions. It is strange that we had to explicitly give these permissions when we didn't have to do it in SQL 2000, but it worked.

|||

Just a random thought: Does the schema assigned to the sql server login in question match the name of the login? What schema owns the table in question and what schema is the user in?

|||

dbo

|||

I think that may be your answer. I would try creating a seperate schema for the user in question and disassociate the dbo schema from the user.

RDO or ADO

I am using Crystal Report 10 connected to SQL Server 2000
for report writing. I have the option to choose from ODBC
RDO and OLE DB ADO.
I would like to know which one should I choose ?
What is the difference between them and which one is more
efficient ?
ThanksI suggest you use ADO since it is the successor to RDO.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:68a701c493bb$35cb4d60$a301280a@.phx.gbl...
>I am using Crystal Report 10 connected to SQL Server 2000
> for report writing. I have the option to choose from ODBC
> RDO and OLE DB ADO.
> I would like to know which one should I choose ?
> What is the difference between them and which one is more
> efficient ?
> Thanks|||Peter,
Definitely ADO. Even though ADO is now obsolete (superceded by ADO.NET),
RDO is worse than obsolete. ADO replaced RDO years ago.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
Peter wrote:
> I am using Crystal Report 10 connected to SQL Server 2000
> for report writing. I have the option to choose from ODBC
> RDO and OLE DB ADO.
> I would like to know which one should I choose ?
> What is the difference between them and which one is more
> efficient ?
> Thanks

RDO 2.0 and Visual Basic 5 application stopped working with SQL Server 2005

We have a legacy application that is still in wide use. It is Visual Basic 5 and RDO 2.0 using ODBC to connect to SQL Server database.

When trying to connect to SQL Server 2005, it can no longer update or insert data. It reads data fine. The error message it gives is 16933, "The cursor does not include the table being modified or the table is not updatable through the cursor."

Has anybody else seen this problem? Any help would be appreciated.

Yes, we've seen this. It's hinted at in the documentation, although none of our examples seemed to exactly match what's documented. In several cases we were able to fix the problem by swapping the "from" table with a join table, but in one case we had to give up on the cursor.