When developing socket programs under Win16 the WinSock API (Version 1.1) must be used. (See http://www.sockets.com/winsock.htm[^]). In short... You create a socket with the socket() function. You connect a client socket with the connect(..) function. You read data from a socket with the recv() function (or if asychron what it a must under Win16 via WSAAsyncSelect and windows messaging on FD_READ) You close a connected socket with the closesocket() function. For using this function you must include the winsock.h header. (In the latest MSVC 1.52c version this is included). A very good book for WinSock Programming under Win16 is named book on the website of the above link: Bob Quinn "Windows Sockets Network Programming" A pendant for CloseHandle() in Win32 is not known under Win16. Here you have to handle all socket specific functions with the WinSock API.

in form1.h you define in the class Form 1 the button3_Click method System::Void button3_Click(System::Object * sender, System::EventArgs * e) { BOOL CALLBACK DialogProc (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); hw = CreateDialog( hInstance , MAKEINTRESOURCE ( 102 ) ,NULL,reinterpret_cast(DialogProc )); } This has the parameter sender and e. Because no parameter hInstance is given as parameter into the method and also there is no class parameter with the name hInstance the parameter hInstance cannot be known to the compiler. Where shall it come from? In traditional Win32 SDK development this is given to the main function by windows when the application is started and normally will be kept as global variable in the ugly Win32 SDK style. Here you are in the object oriented world of .NET. Possible there are some method in the Form class allowing access to the application object, where one would typically search for the Win32 style instance handle. (I dont know where exactly). It should also work for this case to set NULL instead of the concrete hInstance value of the application.

Try using SQL Server 2000 commandline tool osql which is the recommended tool for running sql scripts on commandline (if you not need to connect to SQL Server 6.5 or before). All sql server 2000 commandline tool output errors on stdout/stderr and there should be no message box at least. To catch the output it is a good idea to use the -o switch which directs it to the given file. (For more options see sql server 2000 online help "Using the SQL Server Tools) Possibly the messagebox may occur because ShellExecute is used and has this (configured?) effect for the case of a stderr output?

Due to architecture of sql server each database file has a transaction log file for transaction support. Support of transactions are needed for core database functionality. Therefore you can not prevent sql server making transaction logs. Nevertheless the size of transaction log file can be controlled on database creation time with the CREATE DATABASE statement in TRANSACT-SQL. The parameter SIZE, MAXSIZE and FILEGROWTH controls initial size, maximun size and filegrowth for each database file and for log file. Setting the log file size to a fix maximum value is a recommended way not to have a filegrowth over all limits. But this needs maintenance from time to time when MAXSIZE is reached. To reduce the size of an existent transaction log file the TRANSACT-SQL statement (not available from the sql server enterprise manager) DBCC SHRINKFILE can be used. To be secure no other user is modifying database in this time it is a good idea to set the database into the single user mode during this operation. The following are TRANSACT-SQL statements for sql server query analyzer for secure shrinking of the database log file (the log file cannot be lesser than the value given for SIZE during database create time) USE master EXEC sp_dboption myDatabase, 'Single User', TRUE DBCC SHRINKFILE (myDatabaseLog, TRUNCATEONLY) EXEC sp_dboption myDatabase, 'Single User', FALSE GO myDatabase is to replace with the name of the database. myDatabaseLog is to replace with name of the logical name of the logfile of the database. Alternatively to TRUNCATEONLY a target size can specified (which must be equal or greater than SIZE value on create time) A sql server database can consist of multiple data and log files which are grouped in the same or different filegroups. If you have multiple log files you can use EMPTYFILE instead of TRUNCATEONLY to move all used pages to other log files in the same filegroup (on default the filegroup PRIMARY is used; user defined filegroup(s) can exist) to remove this or all log file except the last one needed for each database. For details of the given TRANSACT-SQL command please use the sql server onlinehelp for reference. I Hope this helps.