设计Microsoft Windows NT操作系统上的32位SQL Server 应用程序

设计Microsoft Windows NT操作系统上的32位SQL Server 应用程序

Christopher Moffatt
Microsoft Technical Resources Group

摘要

Microsoft® Windows NT™操作系统是建立充满活力、功能丰富的Microsoft SQL Server应用程序的一个完美的平台。SQL Server Programmer’s Toolkit for Windows NT（SQL Server 程序员Windows NT工具包）含有DB-Library™的32位(Win32™ API)版本，使得开发Windows NT操作系统上的用于Microsoft SQL Server的DB-Library客户端程序成为可能。

这篇技术文章用于将DB-Library开发人员引入到Microsoft Windows NT平台上，讨论的问题包括将已有的Windows™ 3.x和OS/2®操作系统平台上的DB-Library应用程序转换到Windows NT操作系统，并对DB-Library应用程序如何利用Win32应用程序编程接口(API，application programming interface)的一些方法进行了概要说明。

本篇技术文章假定你已熟悉DB-Library API、C语言编程以及下列内容:

·  Microsoft SQL Server Programmer’s Reference for C

·  Microsoft Win32 API Programmer’s Reference, 第1、2卷

·  Converting OS/2 Applications to Windows

建立基于Win32的DB-Library应用程序

下面的章节描述了有关使用Microsoft® Win32™应用程序编程接口(API，Application Programming Interface)建立DB-Library™应用程序的应用。

Win32 DB-Library体系结构

在内部机制上，Win32的DB-Library动态链接库(DLL，dynamic-link library)与OS/2®上的实现方式类似。与在OS/2的一样，在Win32中一个独立的操作系统线程（thread）处理每次DB-Library所发出的与SQL Server的联接。通过调用一个进程（process）所装入的每个DB-Library DLL实例（instance）在共享代码的同时得到了一个私有数据区。

Win32 DB-Library体系结构与在Microsoft Windows™ 3. x中的实现方式不同。在Windows 3.x中，DB-Library DLL只有一个被所有调用的进程共享的数据段。W3DBLIB.DLL通过对单一数据段的联接的一个链接式列表维护DB-Library联接。这种体系结构是需要的，因为在Windows 3.x动态链接库只有一个被所有调用进程共享的数据段。这样就必须通过调用dbinit和dbwinexit函数初始化和清除DB-Library DLL数据结构。

库

Win32的DB-Library函数包含于NTWDBLIB.DLL中，而命名管道（named pipe）驱动程序包含在DBNMPNTW.DLL中。应设置PATH环境变量包含这些动态链接库所在的目录。

另一个文件，NTWDBLIB.LIB，包含了你的应用程序使用Win32 API的引入（import）定义。应设置LIB环境变量包含NTWDBLIB.LIB所在的目录。

包含文件

SQL Server Programmer’s Toolkit for Windows NT™提供了下列包含文件:

包含文件
内容

SQLFRONT.H
错误代码和严重级（severity levels），混合定义（miscellaneous definitions），和类型定义。

SQLDB.H
所有DB-Library函数的函数原型


   你可以在INCLUDE环境变量中添加路径，包含这些包含文件所在的目录。或者你也可以使用/I编译行开关指向包含文件所在的目录。

因为你的使用Win32 API的应用程序必须包含SQLDB.H文件，所以你不需要定义所使用的DB-Library函数。这些函数和它们的正确定义已包含在该包含文件中。你必须在包含DB-Library 包含文件之前定义一个应用程序的操作系统。在所有使用Win32 API设计的DB-Library应用程序的开头包含下列语句；

#define DBNTWIN32

#include <sqlfront.h>

#include <sqldb.h>

你还能通过使用/D编译行参数定义操作系统(例如，使用/DDBNTWIN32 而不是通过一个#define定义)。

编译和链接

下面的例程显示了一个简单的build文件。该文件使用NMAKE工具编译和链接可调试的使用Win32 API的DB-Library应用程序：

NTLIB=\nt\sdk\lib\i386

DBLIB=\sql\dblib\lib

guilibs= $(NTLIB)\gdi32.lib $(NTLIB)\user32.lib $(NTLIB)\

  userrtl.lib $(NTLIB)\kernel32.lib $(NTLIB)\ntdll.lib \

  $(NTLIB)\libcmt.lib

all: sqltestw.exe

# Update the object file if necessary.

sqltestw.obj: sqltestw.c sqltestw.h sqltestw.rc makefile

  cl386 -c -G3d -Di386=1 -DWIN32 sqltest.c

# Update the resource file if necessary.

sqltestw.res: sqltestw.rc sqltestw.h dilaogs.h dialogs.dlg makefile

rc -r -fo sqltestw.tmp sqltest.rc

cvtres -i386 sqltestw.tmp -O sqltestw.res

del sqltestw.tmp

# Update the exe file if necessary.

sqltestw.exe: sql.obj sqltestw.obj sqltestw.res makefile

  link -machine:i386 -subsystem:windows -out:sqltestw.exe\

  -entry:WinMainCRTStartup\

  sqltestw.res sqltestw.obj $(guilibs)\

  ($DBLIB)\ntwdblib.lib

将基于Windows 3.x的DB-Library应用程序转换到Win32环境

所有的DB-Library函数都完全能够在平台间转换。你不需要更改你的任何DB-Library调用。你仅仅需要在编译时定义应用程序的操作系统(例如, 对于Windows NT为#define DBNTWIN32)。

因为Win32 API保持了与Windows 3.x操作系统的兼容性，所以Win32 DB-Library DLL支持所有基于Windows 3.x的DB-Library函数，即使这些函数不需要也是如此。在Windows 3.x出现而在Windows NT中并不需要的DB-Library函数(例如，DBLOCKLIB和DBUNLOCKLIB)可以被使用，但不执行任何操作。

两个DB-Library函数，dbprhead和dbprrow，由于发送输出到STDIO而在Windows 3.x并不被支持，但在Win32中它们能够被支持并用于开发CONSOLE子系统应用程序。dbprhead和dbprrow函数提供了一种简便的方式将查询结果显示到默认输出设备。

如果你希望使已有的基于Windows的DB-Library应用程序能够在Windows NT上运行，你可以采取三种方法:

·  将你的16位Windows 3.x应用程序不加改变的运行于Windows 3.x子系统. 如果你已有Windows 3.x应用程序，你完全不必甚至将来也不需要进行改动，只需要不加改变的运行即可。

·  更改你的应用程序源代码以便其能被编译用于Win32 API或Windows 3.x. 如果你的DB-Library应用程序正在开发或正在改进以满足不断改变的用户需要，以及你希望在Windows 3.x和Windows NT上运行应用程序，从相同的源代码略微进行改动以建立你的16位(Windows 3.x)版本和32位(Win32)版本的应用程序。

·  将你的应用程序源代码完全转换到Win32. 如果你决定更改你的应用程序只作为32位 (基于Win32)应用程序运行（例如，你需要诸如线程和抢先多任务（preemptive multitasking）等Win32特性），你可以将你的应用程序转换到Win32 API上，并删除冗余的Windows 3.x调用和依赖。

在保持DB-Library对Windows 3.x兼容基础上进行转换

本章节解释了如何将用于Windows 3.x的DB-Library应用程序转换到Windows NT操作系统，而同时保持与Windows 3.x应用程序的兼容性。

用于Windows 3.x和C运行时态的API调用

一般而言，你可以改变你的代码轻而易举地建立16位或32位版的应用程序。对于更深入的讨论编写使用Win32 API的且保留了与Windows 3.x兼容性的应用程序，请参阅Microsoft Win32 API Programmer’s Reference第1卷

下面是使用Win32 API的应用程序开发指导方针：

·  函数定义与原型.确保你的函数定义和函数原型使用了可转换的数据类型。

·  Windows 消息参数封装.处理扩宽到32位意味着处理的封装、其它wParam和lParam中的值已经改变。检验你是否需要改变你的应用程序中的wParam和lParam编码。

DB-Library函数和数据类型

所有的DB-Library函数都完全能在操作系统间转换。你只需要在编译的时候定义目标操作系统即可。

许多DB-Library函数的返回值为int型。要注意int数据类型在Windows 3.x中是16位值而在Win32 API中则是32位值。因此，对你的应用程序进行检查以使用正确的变量类型接收返回int数据类型的DB-Library函数所返回的值。例如，一个定义为short数据类型的变量在Windows 3.x中可以从DB-Library接收到正确的int值而在Win32 API中则接收到错误的值。

除了检验接收DB-Library的返回值的变量类型是正确的以外，不需要对DB-Library函数做任何改动。

转换的其它考虑

如果你要将Windows 3.x操作系统的一个应用程序转换到Windows NT操作系统上而不需要保持与Windows 3.x的兼容性，你可以改变你的DB-Library代码，删除冗余或不必要的Windows 3.x函数。

冗余的Windows 3.x专用DB-Library函数

下面的Windows 3.x专用的DB-Library函数在Win32版本的DB-Library是冗余的:

dbinit

在Win32 API中，不需要在引用其它DB-Library函数之前调用dbinit函数。与在MS-DOS&reg;和OS/2&reg;操作系统中的相同，对dbinit的Win32调用返回一个版本字符串。在Windows 3.x中，必须调用dbinit函数初始化DB-Library数据结构。

注意 通常推荐通过调用dbinit来得到DB-Library的版本字符串，并使其可被用户查看(例如，在“About”对话框中)。

dbwinexit

该函数在Win32中不需要。

DBLOCKLIB/DBUNLOCKLIB

在Win32中，每个进程拥有唯一的线性虚拟地址空间，其允许的最大寻址空间为4GB存储器(低端内存的2GB可被用户使用)。在效果上相当于所有的数据存在于一个大的段中，你可以不用关注段、长指针（far pointers）以及其它。这样，你不必在访问指向DB-Library DLL数据的指针或向DB-Library DLL传输数据的指针之前调用DBLOCKLIB和DBUNLOCKLIB宏。

对错误/消息处理器的注册的更改

下面是对Win32的错误和消息处理器的注册的改动：

·  不必输出回调（callback）函数. 你不需要在一个.DEF文件中输出DB-Library错误和消息处理器。

·  不必调用MakeProcInstance. 你不需要调用MakeProcInstance来得到一个传递到dberrhandle和 dbmsghandle的函数。只需要调用dberrhandle 和dbmsghandle，传递函数地址。下面的例程显示了在Windows 3.x和Win32中调用dberrhandle和dbmsghandle函数的不同方式:

对于Windows 3.x:

// Define variables

static FARPROC lpdbMsgHandler;

static FARPROC lpdbErrHandler;



// Get Procedure Instances

lpdbMsgHandler = MakeProcInstance((FARPROC)dbMsgHandler, hInst);

lpdbErrHandler = MakeProcInstance((FARPROC)dbErrHandler, hInst);



// Install the instances into dblib

dbmsghandle(lpdbMessageHandler);

dberrhandle(lpdbErrorHandler);

对于Win32:

// Install the instances into dblib

dbmsghandle(dbMessageHandler);

dberrhandle(dbErrorHandler);

抢先多任务(Win32)与协同多任务(Windows 3.x)

在Windows 3.x中，为了支持协同多任务环境下的同步处理，每个应用程序必须运行良好并按照正常间隔占用CPU。因此，当在Windows操作系统中处理SQL Server查询时，你需要使用基于Windows的定时器或PeekMessage函数与DB-Library函数结合以实现同步处理(dbsqlsend, dbdataready, and dbsqlok)。有关在Windows 3.x中实现同步查询的详细信息，请参阅Microsoft SQL Server Programmer’s Reference for C (43页)。

在Win32 API中对抢先多任务的支持简化了同步查询处理的实现过程。抢先多任务作为Windows NT固有的特性确保了无论其它应用程序的任何进程正在进行处理，另一个程序的进程总能得到CPU周期。在单处理器环境中，同步处理通过使用Win32线程或使用支持与PostMessage Windows函数协作实现同步处理的DB-Library函数而实现。有关同步处理的详细信息，请参阅本文后面的“在DB-Library应用程序中使用Win32 API的特性”内容。

转换SQLTEST3示例应用程序

本章节使用DB-Library Programmer’s Toolkit提供的示例应用程序SQLTEST3作为例子演示如何将一个DB-Library应用程序从Windows 3.x转换到Windows NT。虽然使用的是一个简单的应用程序，但本例能够显示从Windows 3.x操作系统转换应用程序到Windows NT操作系统是多么的容易。

向Win32的最小转换(保持与Windows 3.x的兼容性)

下面的过程显示了如何更改SQLTEST3示例程序以将其转换到Win32 API而同时保持与Windows 3.x的兼容性:

更改操作系统定义:
更改(Windows 3.x):

#define DBMSWIN

到(Win32):

#define DBNTWIN32

改变SQLTEST3.H中的函数原型使其可转换:
更改(Windows 3.x):

long FAR PASCAL SqlTestWndProc(HWND, unsigned, WORD, LONG);

BOOL FAR PASCAL AboutSQL(HWND, unsigned, WORD, LONG);

BOOL FAR PASCAL SelectSQL(HWND, unsigned, WORD, LONG);

BOOL FAR PASCAL ConnectSQL(HWND, unsigned, WORD, LONG);

int dbwinErrorHandler(DBPROCESS *, int, int, int, LPSTR, LPSTR);

int dbwinMessageHandler(DBPROCESS *,DBINT,DBSMALLINT,DBSMALLINT,LPSTR);

到(Win32):

LONG APIENTRY SqlTestWndProc(HWND, UINT, DWORD, LONG);

LONG APIENTRY AboutSQL(HWND, UINT, DWORD, LONG);

LONG APIENTRY SelectSQL(HWND, UINT, DWORD, LONG);

LONG APIENTRY ConnectSQL(HWND, UINT, DWORD, LONG);

int API dbwinErrorHandler(DBPROCESS *, int, int, int, LPSTR, LPSTR);

int API dbwinMessageHandler(DBPROCESS* DBINTDBSMALLINT, DBSMALLINT, LPSTR);

更改下面函数的参数和返回值以匹配在第2步中对函数原型所做的全部改动:
SqlTestWndProc

AboutSQL

SelectSQL

ConnectSQL

dbwinErrorHandler

dbwinMessageHandler

向Win32完全转换

下面的过程显示了如何更改SQLTEST3示例程序以将其转换到Win32 API而同时不保持与Windows 3.x的兼容性: 

删除多余的DB-Library调用:
DBLOCKLIB 或DBUNLOCKLIB (在三个位置)

dbwinexit

改变错误/消息处理器注册:
更改(Windows 3.x):

static FARPROC lpdbwinMessageHandler;

static FARPROC lpdbwinErrorHandler; 

...

lpdbwinMessageHandler =

MakeProcInstance((FARPROC)dbwinMessageHandler, hInst);

lpdbwinErrorHandler =

MakeProcInstance((FARPROC)dbwinErrorHandler, hInst);

dbmsghandle(lpdbwinMessageHandler);

dberrhandle(lpdbwinErrorHandler);

...

FreeProcInstance(lpdbwinMessageHandler)

FreeProcInstance(lpdbwinErrorHandler);

到(Win32):

dbmsghandle(dbwinMessageHandler);

dberrhandle(dbwinErrorHandler);

改变DialogBox实例:
改变所有的DialogBox函数调用以传递函数地址而不是调用MakeProcInstance并传递该函数返回的指针。

删除.DEF文件(不是必须):
将基于OS/2的DB-Library应用程序转换到Win32

所有的DB-Library函数可以在OS/2和Win32 APIs间完全的转换，你不需要对你的DB-Library调用进行任何改动。

如果你希望已有的基于OS/2的DB-Library应用程序能在Windows NT操作系统运行，有两种基本方法可以使用；

·  更改源代码，将基于OS/2和/或Presentation Manager&reg;的函数替换为等效的Win32 API函数。因为C运行时态（run-time）函数和DB-Library函数能够完全转换于OS/2和Windows NT平台间，如果你决定转换一个基于OS/2的应用程序到Windows NT平台，你只需要将基于OS/2和/或Presentation Manager&reg; 的调用替换为等效的Win32 API调用。Converting OS/2 Applications to Windows对该主题进行了详尽地讨论并概述了转移的考虑事项，并深入说明使用Win32 API函数替换基于OS/2和Presentation Manager的函数的过程。Win32 API提供了等效的，在某些情况下功能更多的函数替换OS/2函数。

·  不加改动地运行OS/2字符模式（character-mode）应用程序。Windows NT操作系统的初始版本提供了一个使用二进制兼容运行OS/2字符模式应用程序的OS/2子系统。如果你拥有为OS/2编写的字符模式DB-Library应用程序，你不需要进行任何改动或重建该应用程序就可以在Windows NT平台运行该程序。查阅Windows NT的文档可确定OS/2子系统支持的OS/2函数。

OS/2到Win32 API的转换

如同前面提到的，将应用程序从OS/2转换到Win32 API这个主题在Converting OS/2 Applications to Windows中有全面的说明。本章节着重讨论两个在大量基于OS/2的应用程序中出现的主要功能领域：线程管理（thread management）和同步机制（synchronization mechanisms）。(该内容直接来源于Converting OS/2 Applications to Windows.)

进程和线程

Win32 API提供了与OS/2进程和线程调用等效的功能。除了下面说明的方面，你可以认为它们的功能在概念上是等效的:

·  安全性: Windows NT平台上的Win32提供了完全的安全性，以及可以对包括进程和线程的所有对象分配安全性访问。

·  父进程:在Win32中没有父进程概念。

·  退出列表处理（Exit List Processing）:在Win32 API中不支持退出列表处理在。不过，在一些情况下DLL的装入和卸载条目可用于相似的效果。

·  句柄（Handles）和IDs:在OS/2中，进程和线程由一个ID全局变量确定。在Win32中，线程和进程拥有全局性的Ids和只在特定进程中有效的句柄（HANDLEs）。所有操作进程和线程的函数都需要一个有效的HANDLE。

信号量（Semaphore）与同步（synchronization）

OS/2和Win32 API集都支持两种同步类型：互斥（mutual exclusion）和信号（signaling）。

互斥（Mutual exclusion）

互斥指禁止其它执行线程对一个代码临界区（critical section）进行访问。OS/2和Win32都设计了相应机制，使一个进程内部或进程间的互斥变得容易。

·  DosEnterCritSec和DosExitCritSec提供了OS/2的互斥机制，当一个线程位于两个调用之间时防止一个进程中的其它线程执行。Win32没有相似的机制。使用这些调用的程序应该组织其代码以便能够访问一个保护资源的所有代码被放于一处，这样可被其它互斥机制所保护。

·  DosFSRamSemClear和DosFSRamSemRequest用于实现在一个进程内部的互斥机制。Win32中提供了Mutex对象实现该功能。有关Mutex对象的有效调用包括CreateMutex、OpenMutex、ReleaseMutex、WaitForSingleObject和CloseHandle。一个Mutex能够被多个进程共享。

·  DosCreateSem、DosOpenSem、DosCloseSem、DosSemRequest和DosSemClear用于进程间的互斥机制。在Win32中提供了Semaphore对象，该对象提供了这些函数的超集。Win32的Semaphore可以是命名的或未命名的，这就提供对RAM信号量或系统信号量的替代品。Win32中管理Semaphore对象的函数包括CreateSemaphore、OpenSemaphore、CloseSemaphore、 ReleaseSemaphore和WaitForSingleObject。

信号（Signaling）

OS/2信号量可用于进程间的信号机制。OS/2中实现该用途的函数为DosSemSet、DosSemWait、DosSemSetWait和DosMuxSemWait。Win32 API提供了Event对象，该对象实现了该功能的一个超集。在Win32中，管理Event对象的函数包括CreateEvent、OpenEvent、SetEvent、PulseEvent和ResetEvent。

在DB-Library应用程序中使用Win32 API 的特性

下面的章节说明了如何利用Win32 API特有的特性。

异步查询处理

Win32 API的抢先多任务使得易于实现异步查询处理。有几种方式可以完成异步查询处理，这取决于是否你希望你的应用程序在进程间或一个进程内存在异步行为。

·  在进程间切换任务. 使用标准dbsqlexec调用发送一个请求给SQL Server。虽然从调用线程的角度dbsqlexec是同步的(只有当SQL Server处理查询后并准备返回结果时dbsqlexec才会返回)，Win32的抢先特性允许其它应用程序或同一程序中的线程在查询执行过程中继续进行工作和处理用户输入。

·  在单进程内实现异步处理。

·  使用线程. 在一个进程内部实现异步处理的最简单方法是使用Win32的线程。你可以运行一个调用dbsqlexec的线程并在查询进行过程中继续做其它工作或接收用户输入。

·  单线程方法. 如果你需要一个单线程进程来实现异步查询处理，将异步DB-Library函数dbsqlsend、dbdataready和dbsqlok与PostMessage函数协同使用，如本例所示:

case WM_SENDQUERY:

  dbsqlsend (dbproc);

  PostMessage(hWnd,WM_CHECKQUERY,0,0L);

  break;



case WM_CHECKQUERY:

  if ( dbdataready(dbproc) )

  {

   dbsqlok (dbproc);

   PostMessage(hWnd,WM_GETRESULTS,0,0L);

  }

  else

  {

   PostMessage(hWnd,WM_CHECKQUERY,0,0L);

  }

break;

Win32内存管理

Win32 API进程所使用的32位虚拟内存地址空间使得内存管理变得简单而清楚。同任何其它使用Win32 API的编程一样，DB-Library编程也能够利用该特性。

虽然Win32 API支持Windows 3.x中的内存管理函数(GlobalAlloc、LocalAlloc以及其它)，但在开发只使用Win32运行的应用程序时，应考虑使用C 运行时态函数malloc和free进行动态内存管理。由于Windows 3.x和OS/2中的分段体系结构的原因，malloc和free函数在这些系统中使用并不安全。然而，在Win32中这些函数即安全又高级。除了标准内存管理函数 (Global和Local, C运行时态支持)外，对于需要特别内存管理的应用程序Win32还提供了堆（heap）和虚拟内存管理函数。

DB-Library编程的两个特定方面可以利用超过64K数据寻址的能力:

·  文本和图像数据的处理. SQL Server的文本和图像数据类型有许多应用。所有的应用都需要操作文本和图像数据，以及在应用程序和SQL Server传输数据。大内存区寻址的能力可以使这些变得简单。因为在使用Win32 API的应用程序中用户内存区最大寻址可达2GB，所以你可以编制文本/图像处理函数，从而使用一个简单的操作即可传输文本/图像数据而不是传输低于64K的数据区。(不过要注意，传输2GB数据的时间会相当的长)

·  行缓冲（Row buffering）.在用于MS-DOS、OS/2和Windows 3.x的DB-Library应用程序中你会感到不便，因为DB-Library一次无法处理超过64K的数据，包括行缓冲的内存分配。而且这个数值由于数据结构、变量和其它所占用的空间而被进一步减少。在Win32中，可以使用DBSETOPT(DBBUFFER,...)实现超过64K的数据集的行缓冲。

Win32的线程

Win32的多线程处理结构开启了实现强大而高级的高端（high-end）应用程序方案的大门。一个进程中的每个线程拥有自己的栈（stack）和机器状态（machine state）。在使用Windows NT平台的多处理器系统中，多个线程可以在不同处理器上同时执行。需要进行大量处理、I/O和其它工作的应用程序可以在后台使用线程实现这些工作，同时在前台仍保持可响应的用户界面。

DB-Library和重入（Reentrancy）

DB-Library API在基础上是非重入的，因为所有访问命名管道联接的DB-Library函数是不可重入的。在多线程应用程序中你必须指定访问命名管道联接的DB-Library调用。

·  在有多个线程访问一个DBPROCESS的应用程序中，指定访问命名管道联接的DB-Library函数 (例如，dbsqlexec、dbsqlsend、dbdataready、dbcancel、dbsqlok和其它) 是必要的。

·  如果每个线程访问一个不同的DBPROCESS，除了对涉及全局变量的操作外你不需要做特别的关注。错误和消息处理在DB-Library内进行全局管理;因此当一个错误或消息发生时，你应该锁定一个信号量或使用一个标志变量，以便不被另一个线程抢先。传送到错误/消息处理器的DBPROCESS将确定所涉及的线程。或者你可以使用dbsetuserdata/dbgetuserdata存储一个线程及相关DBPROCESS的信息。

超时在DB-Library内也是进行全局管理。

结构化异常处理（Structured Exception Handling）

Win32 API支持结构化异常处理以帮助开发充满活力的软件，并通过编译器的支持而可被开发人员所使用。应在你的应用程序中考虑使用该项功能。有关结构化异常处理的详细信息，请参阅Microsoft Win32 API Programmer’s Reference,第1卷(11章)。

对称多处理（Symmetric Multiprocessing）

Windows NT平台支持对称多处理（SMP，symmetric multiprocessing），因而可使多个线程在多个处理器上执行。如果你的DB-Library应用程序使用了Win32线程，那不必做任何工作该程序就能利用Windows NT支持的SMP特性。

例代码: SQLSTRES

SQLSTRES是一个基于Windows NT的DB-Library应用程序示例。它用于模拟大量的SQL Server客户端以帮助确定当新用户加入后“扩展”一个应用程序的效果。

当开发一个SQL Server客户端应用程序时，常常会有一些问题，比如当部署应用程序和大量用户同时使用该程序时，对响应时间和吞吐量的影响如何。标准测试指标（benchmark）有助于了解性能和伸缩性，但这些因素往往波动很大而且很大程度上依赖于一个特定应用程序所执行的查询和更新的类型。在应用程序的开发阶段，经常难以模拟实际的具有大量工作站的环境。SQLSTRES程序允许在单工作站上运行你的程序模拟大量用户执行操作:

·  SQLSTRES使用Windows NT线程模拟每个客户端联接，将状态和查询结果显示在MDI子窗口。

·  SQLSTRES装入了从兼容isql文本文件中执行的Transact-SQL&#8482;查询，使你易于控制执行的查询。

·  SQLSTRES允许你设定所模拟的客户端的数目以及操作反复执行的次数。

这里说明的例代码可以在Microsoft Online Software Library或CompuServe&reg;上的Microsoft Forum Software Library中名为SQLSTRES.ZIP文件中找到。在Microsoft KnowledgeBase中可以查询关键字SQLSTRES、本文的Q号码（Q number）Q87953或S13580。 SQLSTRES.ZIP已使用Pkware文件压缩工具压缩。

SQLSTRES.ZIP 包含下列文件:

文件名称
说明

SQLSTRES.C
主要的源代码文件

SQLSTRES.H
源代码的头文件

SQLSTRES.RC
基于Windows的资源描述文件

SQL.C
DB-Library特定函数的源代码文件

SQL.H
DB-Library特定函数的头文件

DIALOGS.DLG
对话框资源描述文件

DIALOGS.H
对话框头文件

DIALOGS.RES
基于Windows NT的对话框编辑器（Dialog Editor）资源

MAKEFILE
NMAKE文件

TESTX.SQL
查询示例文件


参考文献

书籍

Microsoft SQL Server Programmer’s Reference for C (Part number 27445)

Microsoft Win32 API Programmer’s Reference, 第1、2卷 (Microsoft Press)

Converting OS/2 Applications to Windows (Part number 098-35176)

附加信息

欲得到更多信息，请联系Microsoft Inside Sales, Systems Software, at 1-800-227-4679。

原文转自：http://www.ltesting.net