After doing try catch within the error block I caught such exception:
System.Data.SqlClient.SqlException: @dtExpireDate is not a parameter for procedure pr_EditTreatInstrument. at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream) at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at.... so on
and when I excluded @dtExpireDate, then I see exception like
System.Data.SqlClient.SqlException: Procedure 'pr_EditTreatInstrument' excepts parameter '@dtExpireDate', which was not supplied. at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream) at... so on
Thank you, Sudee
You need a head to program. Cool, fast and sharp.
I have just noticed a problem in my db with the date format. The problem is that some servers are set to interpret dates differently, eg mm/dd/yy or dd/mm/yy. My problem is to find out which it needs and which to supply. I have also been told that the format of dates is an int, and just adds to 1/1/1900 to get the desired result. I am not sure how this works, but it sounds like it could fix my problem.
If you know of a way that I can parse a date to the db, and it will then decide how to format it, or whatever solution you have in mind, please let me know.
The most reliable and cross-platform compatible way of handling dates that i have found it to use the format "YYYY-MM-DD", optionally "YYYY-MM-DD HH:MM:SS". It's unambiguous, and every DBMS i've used handles it fine.
If you're using MS SQL Server though, you can use any format you like, and remove ambiguity before your query using "set dateformat". see books online for that.
I'm with Jon. Either use an ODBC Canonical date (YYYY-MM-DD HH:mm:SS.ffff) or use an ISO standard date (YYYYMMDD HH:mm:SS.ffff) Any DB server, regardless of regional settings, should correctly handle either of these formats.
Thanks. But I dont think it's in the article though. I haven't gone thru it all yet. But read up to the section on ALGORITHM class implementation (stub code) and the include files mentioned are nowhere to be found.
DmhMemory.h and DmhMemory.cpp
DmhLocalization.h and DmhLocalization.cpp
ParamHandler.h, and ParamHandler.cpp
dmalgo.h and oledbdm.h
And they're not in article or Analysis Services installation directory.
I have an access database, and I have a small program that is using an OLEDBDataAdapater to retrieve the information. The problem is that it pulls multiple items (which it must be able to do.) I need to be able to bind the results to a textbox or some control that allows for multiple selection with copy ability. Any help would be greatly appriciated. TIA
Thanks for your suggestion,
unfortunately that won't work in my case.
I'm distributing the application on CD and want it to install a complete SQLServer database on the target machine along with the application itself.
So no way will the target machine have access to the SQLServer on my development machine.
mav.northwind wrote: So no way will the target machine have access to the SQLServer on my development machine.
A lot depends on how much data. In the cases where I don't have direct access to the second Sql box. I tend to create a DTS package that exports to a CSV/XML or other file. Then have a DTS package that imports the data.
I often resort to having a VB app doing all the work as the DTS package can be created as VB source code
In other cases I have my data in an XML format and use SQL Commands to insert the data into another server.
There is also the BCP[^] tool that comes with SQL Server.
Thank you, Michael!
I've actually found an application doing something like this here on CP, but with Graham's tip (see below) we can save all this 'voodoo' and just detach the live database, deploy it and than re-attach. Seems much easier.
You could detach the database on your development machine (you then get a standalone .mdf file), ship that with your app, and attach it to the target SQL server. That way, you'll get everything in the original database (because it's a direct copy).
Attching/detaching the database is easy - just use the sp_attach_db and sp_detach_db stored procedures.
Can we write in one script file that copy the .mdf file and .ldf file to the target machine and attach it to SQL server? This process should be done during or after the process of install the application. If it is possible, then it would be greate!!
It consists of two parts:
1) One InstallerClass that can copy files from the installation source directory to the target directory, replacing certain parameters in the process
2) Calling osql with the script created in step 1
The database files are included as regular files in the setup project and installed in a 'Database' subdirectory of the target directory.
Then I've added a custom action that, after all the files have been installed successfully, copies an sql template file to the target directory and fills in the real path to the database files.
Another custom action then calls osql -E -i <scriptCreatedInStep1>.
The script contents are just:
exec sp_attach_db @dbname='OurDatabaseName', @filename1='$(TRGDIR)\Database\MyDB.mdf', @filename2='$(TRGDIR)\Database\MyDB_Log.ldf'
and $(TRGDIR) gets replaced by the directory my program gets installed to.
As an aside, you don't need to ship or attach the .ldf file. SQL Server will create one if you don't specify one as part of the sp_attach_db stored procedure. Might make the application slightly smaller when distributing it.
Last Visit: 31-Dec-99 18:00 Last Update: 2-Oct-23 8:24