Excel DBCC Error

Forgive me for cross-posting but this involves ODBC as well.
I'm getting "User 'Test1' does not have permission to run DBCC TRACEON."
when trying to connect Excel to SQL Server 2005 using an ODBC System
DSN. I've discovered that this is due to Excel or, more appropriately
MSQuery, attempting to set traceflag 208 having to do with quoted names.
What I haven't found out is how to correct this without granting
SysAdmin privs to users needing to run those queries.
Is there a way to do this without those privs?
Thanx,
GarthI have the exact same problem. Did you find how to correct this without
granting sysadmin privs?
--
Thanks in advance.
Ade
"Garth Keesler" wrote:

> Forgive me for cross-posting but this involves ODBC as well.
> I'm getting "User 'Test1' does not have permission to run DBCC TRACEON."
> when trying to connect Excel to SQL Server 2005 using an ODBC System
> DSN. I've discovered that this is due to Excel or, more appropriately
> MSQuery, attempting to set traceflag 208 having to do with quoted names.
> What I haven't found out is how to correct this without granting
> SysAdmin privs to users needing to run those queries.
> Is there a way to do this without those privs?
> Thanx,
> Garth
>
>

Excel DBCC Error

Forgive me for cross-posting but this involves ODBC as well.
I'm getting "User 'Test1' does not have permission to run DBCC TRACEON."
when trying to connect Excel to SQL Server 2005 using an ODBC System
DSN. I've discovered that this is due to Excel or, more appropriately
MSQuery, attempting to set traceflag 208 having to do with quoted names.
What I haven't found out is how to correct this without granting
SysAdmin privs to users needing to run those queries.
Is there a way to do this without those privs?
Thanx,
Garth
I have the exact same problem. Did you find how to correct this without
granting sysadmin privs?
Thanks in advance.
Ade
"Garth Keesler" wrote:

> Forgive me for cross-posting but this involves ODBC as well.
> I'm getting "User 'Test1' does not have permission to run DBCC TRACEON."
> when trying to connect Excel to SQL Server 2005 using an ODBC System
> DSN. I've discovered that this is due to Excel or, more appropriately
> MSQuery, attempting to set traceflag 208 having to do with quoted names.
> What I haven't found out is how to correct this without granting
> SysAdmin privs to users needing to run those queries.
> Is there a way to do this without those privs?
> Thanx,
> Garth
>
>

Excel as a Data Source

I am building a report that uses an Excel Doc as its data source. I used a
system ODBC as the data connector, and taht works fine per the test button,
but I am not sure what the query syntax would look like. Any help would be
greatly appreciated!!
Thanks!Never mind. After much trial and error, I got the syntax down:
select * from [<sheet name>$] where <column name>=<value>
"Carl Henthorn" wrote:
> I am building a report that uses an Excel Doc as its data source. I used a
> system ODBC as the data connector, and taht works fine per the test button,
> but I am not sure what the query syntax would look like. Any help would be
> greatly appreciated!!
> Thanks!

Every query returns 'S1C00 - optional feature not implemented. HELP !

Greetings
I'm running;
- win2k
- SQL Server 7.0 with SP4
- "SQL Server" ODBC driver version 2000.85.1117.00
We have an sql server 7.0 database that gets updated every day by a
small app (also running on the database server machine). It uses the
'SQL Server' ODBC driver that was installed when SQL Server was
installed on this win2k machine. This system has been running
faultlessly for almost 18 months (so something has changed; I don't
know whether its the system software, something about the application
data ... this system is well protected by antivirus and firewalls on an
internal network but no tripwire ly).
So last friday (early in the morning before anybody arrived at work)
this app started issuing S1C00 messages ('optional feature not
implemented') for almost every SQL query submitted via this ODBC driver
(even simple select, simple varchar field updates and commit - there is
an example from an ODBC trace below - The same queries work fine when
submitted with ISQL). Log entries and inspections of the data suggest
that Friday's run got almost right through before the errors began.
The same S1C00 message occurs using third party (datadirect) commercial
ODBC driver, and I've just spent the night upgrading applying patches
to win2k and sql server and testing, but the problem appears to remain
unchanged.
Is there anything about SQL Server configuration that would/could cause
'optional feature not implemented' messages?
Also, I've been trying to identify the latest SQL Server ODBC driver.
It seem to be 3.7, so I don't understand why the ODBC administrator is
showing 2000.85.1117.00 as the driver version on this system. Anyone
shed any light on that?
Any and all help will be very much appreciated.
Kind regards,
Darius
DbDailyUpdate 53c-50c EXIT SQLExecDirect with return code -1
(SQL_ERROR)
HSTMT 1CD72338
UCHAR * 0x1CCD0F60 [ -3] "SELECT * FROM tysclt WHERE
clientid = '216582'\ 0"
SDWORD -3
DIAG [S1C00] [Microsoft][ODBC SQL Server Driver]Optional feature not
implemented (0)See if this information helps you:
http://support.microsoft.com/defaul...kb;en-us;214459
Most probably your application code has changed.
--
Vikram Vamshi
Database Engineer
Eclipsys Corporation
"Darius" <dariusq2km@.yahoo.com> wrote in message
news:1123620825.806034.103840@.g47g2000cwa.googlegroups.com...
> Greetings
> I'm running;
> - win2k
> - SQL Server 7.0 with SP4
> - "SQL Server" ODBC driver version 2000.85.1117.00
> We have an sql server 7.0 database that gets updated every day by a
> small app (also running on the database server machine). It uses the
> 'SQL Server' ODBC driver that was installed when SQL Server was
> installed on this win2k machine. This system has been running
> faultlessly for almost 18 months (so something has changed; I don't
> know whether its the system software, something about the application
> data ... this system is well protected by antivirus and firewalls on an
> internal network but no tripwire ly).
> So last friday (early in the morning before anybody arrived at work)
> this app started issuing S1C00 messages ('optional feature not
> implemented') for almost every SQL query submitted via this ODBC driver
> (even simple select, simple varchar field updates and commit - there is
> an example from an ODBC trace below - The same queries work fine when
> submitted with ISQL). Log entries and inspections of the data suggest
> that Friday's run got almost right through before the errors began.
> The same S1C00 message occurs using third party (datadirect) commercial
> ODBC driver, and I've just spent the night upgrading applying patches
> to win2k and sql server and testing, but the problem appears to remain
> unchanged.
> Is there anything about SQL Server configuration that would/could cause
> 'optional feature not implemented' messages?
> Also, I've been trying to identify the latest SQL Server ODBC driver.
> It seem to be 3.7, so I don't understand why the ODBC administrator is
> showing 2000.85.1117.00 as the driver version on this system. Anyone
> shed any light on that?
> Any and all help will be very much appreciated.
> Kind regards,
> Darius
> --
> DbDailyUpdate 53c-50c EXIT SQLExecDirect with return code -1
> (SQL_ERROR)
> HSTMT 1CD72338
> UCHAR * 0x1CCD0F60 [ -3] "SELECT * FROM tysclt WHERE
> clientid = '216582'\ 0"
> SDWORD -3
> DIAG [S1C00] [Microsoft][ODBC SQL Server Driver]Optional feature not
> implemented (0)
>|||Hi Vikram,
Thanks for the response and the link - see below for inline reply ...
Vikram Vamshi wrote:
> news:1123620825.806034.103840@.g47g2000cwa.googlegroups.com...
> See if this information helps you:
> http://support.microsoft.com/defaul...kb;en-us;214459
> Most probably your application code has changed.
> --
> Vikram Vamshi
> Database Engineer
> Eclipsys Corporation
The application code hasn't changed. The app is compiled java (stored
in and run from jars and gets at ODBC via JDBCODBC. The jars were last
replaced over six months ago and i am the only maintainer of the
source.
There are no stored procedure calls.
Many of the queries that fail with the 'S1C00' code contain no
date/time types and no decimals.
I've tried using a different machine (XP with different ODBC drivers)
to run this app against the sql server machine, but same result
(S1C00). So, I'm thinking something is wrong with the way the server is
responding to the driver, since it doesn't seem to matter where the
client runs, but I don't know if this makes sense because I think the
driver knows what data types can be handled or translated without
interacting with the server.
Ss I said earlier, it seems any and every query can or does get S1C00
including a single-field varchar 'update', 'select' (as above) and
'commit' :0
Thanks for your thoughts,
Darius