Ok, I give up...

Been working in Visual Studio 2005 and got to the point where
I needed to build a native program that interfaces with SQL Server
via the bulk copy API. So, I d/l'ed SQL Server 2005, installed it
and tried a simple example from MSDN from the bcp_bind
documentation.
Fails because it is unable to find "sqlfront.h." I search the web.
Best suggestion I can find is to install the "Platform SDK" Installed
that. Installed everything I could find from the SQL Server 2005
distribution CDs. "sqlfront.h" is not in
"Visual Studio 8/VC/PlatformSDK/include or
"VIsual Studio 8/VC/include", where I would have thought they might
end up.
Found a reference that indicated there may be some kind of SQL
Server SDK that I might need to download, but so far I've been unable
to find one. Other suggestions indicate it may be included in the
Platform SDK, but I already tried that, no cigar...
Did a search of the whole computer. It found a copy of sqlfront.h,
one in "Microsoft Visual Studio/VC98/include"-- which is one from
VS 6.0, as I also have VS 6.0 on this system as that is what our
current development uses, we're trying to move some things to
.NET, and that's the only one it found.. Can I just use the includes
from VS 6.0? Are these the latest ones and that's why I've been
unable to find ones for VS 2005? Did Platform SDK install it in
the wrong tree? If so, how do I correct for that? Can VS 2005
link with the associated library files from VS 6.0? How are you
*supposed* to get these darn files so the stupid example will
compile?
I'm on XP SP2 BTW, if that is of any relevance.
Uninstalling VS 6.0 is not an option, that's what all our current
development is using. Installing VS 2005 on another PC is
not an option, I'm the only developer in this particular office and
they aren't going to buy me a new PC to do this. Deciding NOT
to transition to .NET and VS 2005 is an option however, and the
one I'm currently giving the most serious consideration. Uninstalling
VS 2005 and going to VS 2003 or something could be an option,
but it would be nice to know if it would actually fix the problem.
Reverting to an eariler SQL Server version could be an option as
well, but again, it'd be nice to know that it would actually fix the
problem.
I also noted that doing searches for stuff on MSDN does not
make it very clear WHICH version of whatever (VS, VC++,
SQL Server, etc.) the information applies to. Often I would find
pages and wonder if it applies to the .NET version or is leftover
from some previous incarnation of the product and possibly no
longer applies to the .NET version. Best I can tell, you can't
restrict searches by product version (if I'm wrong, please enlighten
me). What a nightmare-- I've just spent 2 days trying to get the
simplest of example programs to compile a native program on
VS 2005. Plenty of other people seem to have inquired about
the location of sqlfront.h though, I notice, yet so far I've not found
a response that was helpful to me.
Has ANYONE been able to compile a native VC++ program that
talks to SQL Server on the 2005 versions of VS & SQL Server?
Was it my mistake because I happened to choose to try
the "latest" versions of these products just as they came out,
and thought I could actually do something useful with them?
If you've been able to make it work, where does your sqlfront.h file
live on your system? Any idea how it got there?
Sync"sqlfront.h" and all the other include files and libraries you'll
need will typically be found in
C:\Program Files\Microsoft SQL Server\80\Tools\DevTools
During SQL Server installation make sure you check the "Development
Tool" option.
I've quite happily built native C++ programs that use
bcp_bind/bcp_sendrow/bcp_batch etc.
using Visual Studio .NET 2003|||Somone else just informed me of the DevTools... I have an 80\Tools
directory and a 90\Tools directory but no DevTools under either. I'm
sure I would have checked any "development" options in the install, as
that is all I'm doing-- this is not a production system it's purely a
development system. I'm currently searching for "sqlfront.*" on the
installation media, after I finish that I'll try the Sql Server
installation again and see if I can find something I missed...
So far, explorer search hasn't found sqlfront.* on either of the two VS
2005 CDs or the
SQL Server 2005 Developer Edition CDs, and it apparently does search
the .cab
files. Silly me though, perhaps I was assuming that such an include
file would be
on the DEVELOPER edition of SQL Server, maybe I should try the standard
edition...
Thanks for the info,
Sync|||I checked-- in Workstation Components, books online and development
tools, it shows everything in Client Compoments including Software
Development Kit as being installed.
Database Services, Analysis Services, Integration Services,
Notification Services show not installed. However, if I select them to
be installed and continue, it ultimately tells me everything is already
installed and so there's nothing for it to do.
I'm thinking I need to blow away the entire SQL Server installation and
reinstall absolutely EVERYTHING and see where that gets me. I did
install it in pieces somewhat originally, because I didn't know where
they had hidden the darn development tools-- apparently in
"documentation" which I usually think is huge and mostly already
available online, so I didn't install it. And, installing it later
seems to have
left it half uninstalled and thinking it's all installed...
Sync|||AAAAAAARRRRRRRGGGGGGHHHHHH!!!!
Looks like they merely renamed the include files and didn't tell me
anywhere-- the
bcp_bind example was for SQL Server 2000, and it hasn't been updated.
Apparently, "sqlfront.h" and "sqldb.h" no longer exist. The old bulk
copy functions
are now ODBC based and use the include "sqlncli.h" and an odbc handle
instead of
a DBPROCESS structure. There was an article in the books online
entitled
"Converting from DB Library to ODBC Bulk Copy functions" that explains
the
difference, which I never found because I didn't know about it and
doesn't mention
the differences in the includes, which is what breaks when you try the
example found
on the MSDN library (which is for SQL Server 2000).
So, I'm going to work on converting the example to an ODBC version
based on the
articles I've found.....
Syncsql

ODBC to SQL Express - SQL Driver versus SQL Native Client

I have a SQL express database which I need to access from a shared hosting plan. I can create an ODBC connection through the hosting provider's control panel for SQL Server, but it won't connect. I tested this locally and discovered that the SQL Native Client connects fine, but the previous SQL Server driver does not. This seems to only happen with SQL 2005 Express edition; it works with the Developer Edition. Does SQL Express only use the Native SQL Client?

Thanks in advance for your help!

NO, it does not, you can connect using the ADO / ADO.NET as well. Which error information do you get ? Are you using a user instance ? This is though only supported by the SNAC client.

Jens K. Suessmeyer

http://www.sqlserver2005.de

|||

Thank you!!! The issue was that it was installed as a user instance and not the default instance. With a user instance, you can apparently only connect using the SQL Native Client. I reinstalled SQL 2005 Express as the default instance and the older SQL Server ODBC driver worked!

odbc sql native client

I've installed the SQL Server 2005 client utilities on a laptop that's used
for development. When I try to create an odbc connect to SQL Native Client
2005.90.1399.00 that specific driver doesn't appear in the list of drivers
available for selection. I've verified that it is in fact installed.
What's the problem, why doesn't it appear?
It's hard to say where exactly you are seeing this issue but
I would guess you are trying to create a DSN using the SQL
Native Client. Try updating your MDAC and verify that the
MDAC installation is correct on the laptop. You can check
the MDAC installation using component checker. You can
download component checker as well as the latest MDAC
versions from:
http://msdn2.microsoft.com/en-us/data/aa937730.aspx
-Sue
On Tue, 24 Jul 2007 09:12:01 -0700, gracie
<gracie@.discussions.microsoft.com> wrote:

>I've installed the SQL Server 2005 client utilities on a laptop that's used
>for development. When I try to create an odbc connect to SQL Native Client
>2005.90.1399.00 that specific driver doesn't appear in the list of drivers
>available for selection. I've verified that it is in fact installed.
>What's the problem, why doesn't it appear?
>
>
|||I have a similar issue with one desktop in our office. The SQL Native
Client doesn't appear in the ODBC list when opening up "User DSN".
Nothing seems to be different on this system from the 20 others that
it does appear on. MDAC is the latest one also. Have any other ideas
of what I might look for?
Sue Hoegemeier wrote:[vbcol=seagreen]
> It's hard to say where exactly you are seeing this issue but
> I would guess you are trying to create a DSN using the SQL
> Native Client. Try updating your MDAC and verify that the
> MDAC installation is correct on the laptop. You can check
> the MDAC installation using component checker. You can
> download component checker as well as the latest MDAC
> versions from:
> http://msdn2.microsoft.com/en-us/data/aa937730.aspx
> -Sue
> On Tue, 24 Jul 2007 09:12:01 -0700, gracie
> <gracie@.discussions.microsoft.com> wrote:

ODBC Returning success but actually failing (SQL Native)

I'm talking to SQL 2005 using the SQL Native client in ODBC:

Here's what I'm doing:

1) SQLPrepare () -- Prepair an insert stmt
2) SQLBindParameter() -- Binding the parameter
3) Set the Parameter to a value
4) SQLExecute() -- Execute the statment
5) Set the Parameter to a different value
6) SQLExecute() -- Execute the statment

Both calls to SQLExecute() return SUCCESS_WITH_INFO.

The problem is that only the 1st SQLExecute() ever makes it to the database. The second SQLExecute() never gets executed at the database AND it returns a success condition.

When I check what the info is, it's "[Microsoft][SQL Native Client]Fractional truncation". Not an issue since I'm setting a datetime value in the database and I don't care about the milliseconds.

Here's the problems with this:

1) SQLExecute() return success yet it does not execute the statement. How can I tell if the statement fails if SQLExecute() always return success?

2) Why does a previous success with info cause all future executes to not happen?

So, is there a way to tell odbc to ignore the info and allow the next execute to run?

Thanks for any help,

Scott

Could you send some sample code that demonstrates the problem please?

How do you know the 2nd execute is not making it to the server? How you looked at a profiler trace or are you just examining the database?

|||

I'm use SQL Server profiler to determine the second SQLExecute is never making it to the database.

I've done some more testing on this and here's what I have found:

1) The problem exists with the "SQL Native Client" ODBC driver. The "SQL Server" does not have this problem. Switching to the "SQL Server" driver fixes the problem.

2) The problem seems to exist only when using the SQL

Here's how to reproduce the problem:

Step 1: In SQL 2005, create table with a datetime field. Here's the code I used:
CREATE TABLE [dbo].[TestTbl] ( [TestDate] [datetime] NULL )

Step 2: Create an ODBC connection to this table using the SQL Native Client driver. In my example, I called it "TestNative"

Step 3: Here's the VC++ code that uses ODBC to connect to the database and insert data into the TestTbl table:

-- BEGIN CODE BLOCK
CDatabase db;
db.OpenEx ("DSN=TestNative;APP=Test App;WSID=SCOTT1;DATABASE=Test2;Trusted_Connection=Yes", CDatabase::noOdbcDialog);

HSTMT hstmt;
::SQLAllocHandle (SQL_HANDLE_STMT, db.m_hdbc, &hstmt);

LPCTSTR strSQL = ;
::SQLPrepare (hstmt, (SQLCHAR *) "INSERT INTO TestTbl (TestDate) VALUES (?)", SQL_NTS);

SQL_TIMESTAMP_STRUCT sqlTimestamp;
SQLLEN Ind = sizeof (sqlTimestamp);
::SQLBindParameter (hstmt, 1, SQL_PARAM_INPUT, SQL_C_TIMESTAMP, SQL_TIMESTAMP, 0, 4, &sqlTimestamp, Ind, &Ind);

sqlTimestamp.year = 2006;
sqlTimestamp.month = 6;
sqlTimestamp.day = 1;
sqlTimestamp.hour = 1;
sqlTimestamp.minute = 1;
sqlTimestamp.second = 1;
sqlTimestamp.fraction = 0;
::SQLExecute (hstmt);

sqlTimestamp.day = 2;
::SQLExecute (hstmt);

::SQLFreeHandle (SQL_HANDLE_STMT, &hstmt);
-- END CODE BLOCK

Using the ODBC "SQL Server" driver, this code inserts 2 records into TestTbl.
Using the ODBC "SQL Native Client" drivre, only 1 record gets inserted.

Running SQL Server profiler to monitor what happens in the database, when the first SQLExecute() executes, a "exec sp_prepexec ..." statement is run on server. This happens with both ODBC drivers.
The problem is that with the second SQLExecute() nothing happens in the database if the "SQL Native Client" driver is used. If the "SQL Server" driver is used, "exec sp_execute 1,''2006-06-02 01:01:00:000''" is run at the server.

|||

I couldn't get the sample code to run as supplied because of an error in SQLBindParameter. You need ColumnSize and DecimalDigits set to 19, 0 or 23, 3. (See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbccolumn_size.asp for details)

Once I'd fixed the problem with SQLBindParameter I got two rows inserted with both SQL Server and SQL Native Client drivers.

I ran my repro as an ODBC v3 app.

If I ran the app as an ODBC v2 app with your settings for SQLBindParameter then I managed to reproduce your problem, but if I ran with 19,0 or 23,3 I got two rows inserted.

So, if you run as an ODBC v3 app (via SQLSetEnvAttr call before connecting) you'll get better diagnostics from SQLBindParameter. Even if not, if you provide correct values for precision and scale on SQLBindParameter the problem will go away.

We'll investigate why the two drivers behave differently.

ODBC Native State S1T00: timeout expired

Hello :
I am very new to ODBC connectivity, but i know sql fairly
well:

What can generate a Native State Error: Native State
S1T00: timeout expired on a SQL 2000 database; NT4 OS
Server??

I am running sql database dependent applications on this
server: 3 to be exact.

e.g. I have an application which transports data that was
entered to the SQL database located on this Server via a
LAN user. This application then dynamically takes this
data and transports it to another device located on the
same sub-net as the Server for data recognition and other
functionalities. This is performed in milliseconds hence
it may be utilizing the (winmm.dll) file to accomplish
this. But the error message:

"Warning State: S1T00,Native:0, Origin: [Microsoft][ODBC
SQL Server Driver] timeout expired"

causes this process to fail along with other ODBC and SQL
dependent applictions. also my maintenance plans failed as aresult of this message..

Can someone please help/ inform me what can cause this and
how to prevent this??

Can a modem dial-in access cause this?? though it was
running fine with modem access in the past, and no change
in its configs.??

Thank you in advance

AdiggaMay check this KBA (http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q175/2/64.asp&NoWebContent=1) .