I am trying to post a date to a dateTime column in a SQL Server 2008 R2 database, but I have run into many problems that I don't know what are the causes.
First, I used this code but I got the error:cannot convert string to date.
ADOOF.SQL.Text:='UPDATE OFTab SET CA='''+ CA.Text + ''', demandeClient=''' + DateTimeToStr(demandeClient.DateTime) + ''' WHERE ID='''+ ADOOF.FieldByName('ID') + '''';
ADOOF.ExecSQL;
Second, I have used parameters:
ADOOF.SQL.Text:='UPDATE OFTab SET CA='''+ CA.Text + ''', demandeClient=:demande_client WHERE ID='''+ ADOOF.FieldByName('ID') + '''';
ADOOF.Parameters.ParamByName('demande_client').Value:= demandeClient.Date;
ADOOF.ExecSQL;
But I got the error: Parameter (demande_client) not found.
I googled this problem and I found a suggestion by Embarcadero saying that the parametres sould be created before calling the ADOQuery like this:
ADOOF.SQL.Text:='UPDATE OFTab SET CA='''+ CA.Text + ''', demandeClient=:demande_client WHERE ID='''+ ADOOF.FieldByName('ID') + '''';
ADOOF.Parameters.ParseSQL(ADOOF.SQL.Text, True);
ADOOF.Parameters.ParamByName('demande_client').Value:= demandeClient.Date;
ADOOF.ExecSQL;
Finely I removed the connection Persist Security Info but always the same problem.
Please, any suggestions.
INFO: I am using MICROSOFT OLE DB Provider For SQL Server.
in your first example use
FormatDateTime('YYYYMMDD hhmmss',demandeClient.DateTime)
instead of
DateTimeToStr(demandeClient.DateTime)
This is because DateTimeToStr without formatsettings uses your localized machine settings and your database just might or might not like the format. Using FormatDateTime also gets rid of ambiguities: consider 01/02/03, for some people on the world this is january 2nd 2003 but for others 1st of februari 2003 and even some will say 2001, februari 3rd. YYYYMMDD is universal. 20030201 is always 1st of februari 2003.
It can depend on how you connect to your DB (drivers).
You can try to explicit that you are using a Date:
ADOOF.Parameters.ParamByName('demande_client').DataType:= ftDateTime;
ADOOF.Parameters.ParamByName('demande_client').AsDateTime:= demandeClient.Date;
I will strongly suggest to use SQL Native Client 11 when you are working with SQL Server 2008 R2. New SQL Server 2008 data types (including DATE, TIME, DATETIME2, and DATETIMEOFFSET) are not supported by the SQL Server 2000 OLEDB provider.
Your second code sample should work. Check that you have TADOQuery.ParamCheck = True.
Related
I have a stored procedure created in MySQL DB. This database is accessed as linked server through Microsoft SQL Server 2012 using Microsoft SQL Server Management Studio. The provider selected while creating linked server is "Microsoft OLE DB Provider for ODBC Drivers".
When I run following as text from Report builder 3.0 it runs fine and fetch data.
EXEC('CALL storedProcedureName(''string1'', ''string2'', ''string3'')') AT LinkedServerName;
But when I try to replace string1, string2, string3 with parameter name parameter1, parameter2, parameter3 as:
EXEC('CALL storedProcedureName(#parameter1, #parameter2, #parameter3)') AT LinkedServerName;
I get error:
Could not execute statement on remote server 'LinkedServerName'.
(Microsoft SQL Server, Error: 7215)
And when I try:
EXEC('CALL storedProcedureName('#parameter1', '#parameter2', '#parameter3')') AT LinkedServerName;
I get the prompt to enter values for parameter1, parameter2, parameter3. But when I enter the values and click ok, I get error:
Incorrect syntax near '#parameter1'. (Microsoft SQL Server, Error: 102)
Question: Am I missing something in syntax or is this a bug?
The linked server has:
"RPC" and "RPC out" set to True.
And the OLEDB provider has:
Enabled allow inprocess
Enabled dynamic parameter
I believe you have to call it like the below. So params become strings wrapped in single quotes:
EXEC('CALL storedProcedureName('''+#parameter1+''', '''+#parameter2+''', '''+#parameter3+''')') AT LinkedServerName;
I know this is an older question but the accepted answer is open to SQL Injection and I think it's important to offer a more secure method.
You really want to use a parameterized query
EXEC('CALL storedProcedureName(?,?,?)',#parameter1, #parameter2, #parameter3) AT LinkedServerName;
I know this works for oracle and it should work for MySql as well.
actually I have developed a web application in MVC 5.0 with Entity framework 6.0, sql server ..
I tried to query a sum value which is Amount(Float in sql server)
SearchDetails.Sum(total => Convert.ToDecimal(total.Amount));
getting
input string was not in a correct format
I took database backup and I tried to run from my side I am getting the value
I have verified in the database all the values are in correct format
I tried to print the values
total.Amount
getting a comma
","
instead of dot
"."
in my PC value is like 300.00 but the same in client PC getting 300,00 ?
Please help.
I have Add this in
in globlization section SET culture = en-US
this solved my issue
Thanks
Please do me a favor, I want to maintain all the stored procedures in one database, let's say SP_Dbase.
I plan this scheme, user application determine dbase_xyz and will go to SP_stored_procedure in SP_Dbase and then retrieve or edit data of dbase_xyz.
Since command Use dbasename does not work in a stored procedure, I have big difficulty.
I don't intend to write down all the procedure as an execute command as follows :
Set #cmd = 'select .... from ' + #DB + '.dbo.tablename'
EXEC(#cmd)
Anyone could help me ?
Note: All databases have same structure and exist in one SQL Server 2008 R2 instance.
Thanks
All my oracle varchar2 data returns empty(EmptyStr) using an firedac connection + firedacQuery. I tryed an ADO connection on same database and all strings appear normally.
Can anyone explain? Im using delphi XE5 + oracle 11g, database charset is WE8ISO8859P15.
I was able to resolve my problem by updating the oci driver.
Embarcadero® Delphi® 2010 Version 14.0.3593.25826
We are attempting to move a database from SQL Server 2000 to SQL Server 2008. I have a TClientDataSet that is loaded with a SELECT that includes a computed column, i.e., "SELECT Comp_Col = Column1 + ' ' + Column2...".
Running against an SQL Server 2000 database, I can modify the value of the column in the TClientDataSet using the following code:
ClientDataSet1.Edit();
ClientDataSet1.FieldByName('Comp_Col').ReadOnly := false;
ClientDataSet1.FieldByName('Comp_Col').Value := 'MODIFIED';
ClientDataSet1.FieldByName('Comp_Col'').ReadOnly := true;
ClientDataSet1.Post(); // <-- EXCEPTION in 2008
Running against an SQL Server 2008 database, though, I get a "Trying to modify read-only field" error when executing .Post().
I have tried also setting .ProviderFlags = '[]' for the column (in addition to .ReadOnly = false) in the above code, but still get the error. I have also tried setting .ReadOnly = false and .ProviderFlags = '[]' at design-time via the IDE, but this does not help either.
Anybody know how to set a computed column in a TClientDataSet when running against an SQL Server 2008 database?
Thanks!
* UPDATE: ANSWERED *
I discovered the problem--or at least a workaround...
I WAS setting .ReadOnly = false for the column in the TClientDataSet object. This worked with SQL Server 2000 but not with SQL Server 2008.
If I set .ReadOnly = false in for the column instead in the TADOQuery object that is serving as the provider, then I am able to set the value of the computed column in the TClientDataSet object at run-time.
Not ideal for me since this was implemented in a generic function for TClientDataSet objects (that didn't anything about the provider), but it will have to do for now.
I discovered the problem--or at least a workaround . . .
I WAS setting .ReadOnly = false for the column in the TClientDataSet object. This worked with SQL Server 2000 but not with SQL Server 2008.
If I set .ReadOnly = false for the column instead in the TADOQuery object that is serving as the provider, then I am able to set the value of the computed column in the TClientDataSet object at run-time.
Not ideal for me since this was implemented in a generic function for TClientDataSet objects (that didn't anything about the provider), but it will have to do for now.
My experience shows that the creation of ClientDataSet fields by calling TClientDataSet.CreaeteDataSet initially without ReadOnly flags solves the problem. After opening ClientDataSet fields' ReadOnly flags can be returned to their seats for the proper functioning of data-aware controls.