I have an SQL Query (MS Access), and I want to add the Date() function into a parameter, however I get the error: [ODBC Microsoft Access Driver]Data type mismatch in criteria expression.
Here is the code:
Qry.SQL.Text := 'SELECT Bookings.Date, Bookings.WeekDay, Bookings.Shift, Bookings.Start, Bookings.Finish,'
+ ' Bookings.DateFinish, Wards.WardName'
+ ' FROM Bookings'
+ ' INNER JOIN Wards ON Bookings.WardNo = Wards.WardNo'
+ ' WHERE (Bookings.NurseNo=:nurseID) AND (Bookings.Date BETWEEN :dateA AND :dateB)'
+ ' ORDER BY Bookings.Date ASC;';
Qry.Params.ParamByName('dateA').Value := 'Date()';
Qry.Params.ParamByName('dateB').Value := 'Date()+6';
I've also tried Qry.Params.ParamByName('dateA').AsString := 'Date()'; but no luck with that, is there a correct way to do this, or would it actually have to be in the query and not parameterised? The reason I want to do it like this, is I will have multiple different queries based on which button is pressed, but the only thing changing is those parameterised dates.
A parameter can't be a function, it has to be a value. You are assigning strings as those values, and those strings do not represent valid dates. That is why you are getting a mismatch error.
You can use Delphi Date() function, and pass the returned TDate as a parameter value:
Qry.Params.ParamByName('dateA').Value := Date();
Qry.Params.ParamByName('dateB').Value := Date()+6;
Or, you can use Access's Date() function in the SQL itself:
Qry.SQL.Text := 'SELECT Bookings.Date, Bookings.WeekDay, Bookings.Shift, Bookings.Start, Bookings.Finish,'
+ ' Bookings.DateFinish, Wards.WardName'
+ ' FROM Bookings'
+ ' INNER JOIN Wards ON Bookings.WardNo = Wards.WardNo'
+ ' WHERE (Bookings.NurseNo=:nurseID) AND (Bookings.Date BETWEEN Date() AND Date() + 6)'
+ ' ORDER BY Bookings.Date ASC;';
Related
Whenever this code runs the I get the above error. The code is supposed to insert a record into a table and then delete records from another table.
for I := iMax - K to iMax do
begin
Inc(a);
with dmMenu.qryMcDonalds do
begin
SQL.Text :=
'SELECT ID, ItemID, ItemPrice, ItemCategory FROM tblCheckout WHERE ID = ' + IntToStr(I);
Open;
sItemID := Fields[1].AsString;
rItemPrice := Fields[2].AsFloat;
sItemCategory := Fields[3].AsString;
ShowMessage(IntToStr(I));
// I get the error here
SQL.Text :=
'INSERT INTO tblOrderItems (OrderItemID, OrderID, ItemID, ItemCategory, ItemPrice) VALUES ("' + sOrderID + '_' + IntToStr(a) + '"' + ', "' + sOrderID + '", "' + sItemID + '", "' + sItemCategory + '", "' + FloatToStrF(rItemPrice, ffCurrency, 10, 2) + '")';
ExecSQL;
SQL.Text := 'DELETE FROM tblCheckout WHERE ID = ' + IntToStr(I);
ExecSQL;
end; // with SQL
end; // for I
edit: I think i the problem is in the 'INSERT INTO' part. All the columns are short text except the last one, ItemPrice is a currency. I am also using Access
Please start a new project with just the following items on the main form:
A TAdoConnection configured to connect to your database;
A TAdoQuery configured to use the TAdoConnection
A TDataSource and TDBGrid configured to display the contents of the TAdoQuery.
Then, add the following code to the form
const
sSelect = 'select * from tblOrderItems';
sInsert = 'insert into tblOrderItems(OrderItemID, OrderID, ItemID, ItemCategory, ItemPrice) '#13#10
+ 'values(:OrderItemID, :OrderID, :ItemID, :ItemCategory, :ItemPrice)';
sOrderItemID = '0999';
sOrderID = '1999';
sItemID = '2999';
sItemCategory = 'Bolt';
fItemPrice = 5.99;
procedure TForm2.FormCreate(Sender: TObject);
begin
AdoQuery1.SQL.Text := sInsert;
AdoQuery1.Prepared := True;
AdoQuery1.Parameters.ParamByName('OrderItemID').Value:= sOrderItemID;
AdoQuery1.Parameters.ParamByName('OrderID').Value := sOrderID;
AdoQuery1.Parameters.ParamByName('ItemID').Value := sItemID;
AdoQuery1.Parameters.ParamByName('ItemCategory').Value := sItemCategory;
AdoQuery1.Parameters.ParamByName('ItemPrice').Value := fItemPrice;
AdoQuery1.ExecSQL;
AdoQuery1.SQL.Text := sSelect;
AdoQuery1.Open;
end;
Before compiling and running the program, review and change the values of the constants
so that they don't conflict with any rows already in your table.
The constant sInsert defines a so-called "parameterised SQL statement" Inside the Values
list, the items :OrderItemID, :OrderID, etc, are placeholders which the AdoQuery will turn into
parameters whose values you can supply at run-time, as in the block after AdoQuery1.Parameters.ParamByName(...
You should always construct SQL statements this way and not by concatenating strings
as your code attempts to do. It is far less error-prone, because it's easy to get into a
syntax muddle if you use DIY code and it also makes sure your queries are not prone
to Sql-Injection exploits, which they would be if you
give the user the opportunity to edit the SQL.
If you are using a FireDAC FDQuery, this has Params (an FD data-type) rather thn Parameters
but they work in pretty much the same way - see the Online Help.
In future, please be a bit more careful to ensure you include important details, especially things like the exact line where the error occurs - which you can check by single-stepping through your code using the debugger - and things like the exact db-access components you are using. Also try to get details right like whether a column is a "short text" type or an autonumber.
For a problem that needs to be debugged, like this one, you should also provide a complete, minimal, reproducible example, not just a snippet of code. Quite often, you will realise what the problem is while you are preparing the mre, so it helps you as well as us.
I bet the problem is in incompatible floating point format.
Use parameters to avoid it.
Is it possible to update a variable with a concatenation of variables(columns of VARCHARS2)?
UPDATE ARTICLE
SET DESCRIPTION = (CPV_DESCRIPTION + '/' LEVEL1_DESCRIPTION + LEVEL2_DESCRIPTION+LEVEL3_DESCRIPTION)
WHERE ID_ARTICULO = 209;
UPDATE ARTICLE
SET DESCRIPTION = concat(CPV_DESCRIPTION,'/',LEVEL1_DESCRIPTION,' ',LEVEL2_DESCRIPTION' 'LEVEL3_DESCRIPTION)
WHERE ID_ARTICULO = 209;
Both cases it gives me an error.
As mentioned by #a_horse... concat() function only takes 2 parameters. When you specify more that 2 parameters to be concated, you need to use || operator. Also + is a logical operator in Oracle unlike its used in Java for concatenation. Try this:
UPDATE ARTICLE
SET DESCRIPTION = CPV_DESCRIPTION
|| '/'
||LEVEL1_DESCRIPTION
||' '
||LEVEL2_DESCRIPTION
||' '
||LEVEL3_DESCRIPTION
WHERE ID_ARTICULO = 209;
I was wondering how to combine Varchar variables in a stored procedure. I want to combine email addresses into a single variable based of access level. I have tried doing a few things in my if statement.
For example I have tried both:
v_m1_email = Concat(v_m1_email, ' , ' , v_email)
and
v_m1_email = v_m1_email || ' , ' || v_email
My code:
CREATE PROCEDURE ALERTEMAIL (OUT p_m1_email VARCHAR(300),
OUT p_m2_email VARCHAR(300),
OUT p_m3_email VARCHAR(300),
OUT p_m4_email VARCHAR(300))
DYNAMIC RESULT SETS 1
P1: BEGIN
DECLARE v_email VARCHAR(50);
DECLARE v_access CHAR(5);
DECLARE v_m1_email VARCHAR(300);
DECLARE v_m2_email VARCHAR(300);
DECLARE v_m3_email VARCHAR(300);
DECLARE v_m4_email VARCHAR(300);
DECLARE SQLSTATE CHAR(5);
DECLARE cursor1 CURSOR WITH RETURN for
SELECT EMAIL,JOB_ID FROM PERSONNEL;
OPEN cursor1;
FETCH cursor1 INTO v_email, v_access;
WHILE (SQLSTATE = '00000') DO
IF v_access = 'Man1' THEN
SET v_m1_email = v_m1_email + ' , ' + v_email;
ELSEIF v_access = 'Man2' THEN
SET v_m2_email = v_m2_email + ' , ' + v_email;
ELSEIF v_access = 'Man3' THEN
SET v_m3_email = v_m3_email + ' , ' + v_email;
ELSEIF v_access = 'Man4' THEN
SET v_m4_email = v_m4_email + ' , ' + v_email;
END IF;
FETCH cursor1 INTO v_email, v_access;
END WHILE;
SET p_m1_email = v_m1_email;
SET p_m2_email = v_m2_email;
SET p_m3_email = v_m3_email;
SET p_m4_email = v_m4_email;
END P1
With regard to the first of what already had been tried from the OP, just as #I_am_Batman on 23-Apr-2016 already noted, the syntax for the CONCAT scalar >>-CONCAT--(--expression1--,--expression2--)------>< is limited to just the two arguments, so the expression coded as Concat(v_m1_email, ' , ' , v_email) would fail, presumably with a sqlcode=-170 suggesting something like "Number of arguments for function CONCAT not valid."
Which variant of DB2 was not noted [not in tag nor by comment in the OP], but I offer this link to some doc DB2 for Linux UNIX and Windows 9.7.0->Database fundamentals->SQL->Functions->Scalar functions->CONCAT
However there is nothing conspicuously incorrect with the second of what already had been tried from the OP; i.e. assuming the assignment and expression shown, had been coded just as shown in the body of the CREATE PROCEDURE, with a preceding SET and a trailing ;. In that case, the statement SET v_m1_email = v_m1_email || ' , ' || v_email; should have been able to pass both syntax-checking and data-type\validity-checking. Whereas what is shown in the OP as SET v_m1_email = v_m1_email + ' , ' + v_email; is not valid except when the values of both variables always would be valid string-representations of numbers; that is because the + operator is a numeric-operator rather than the [conspicuously as-desired] string-operator used to effect concatenation [i.e. for "combining strings"].
[ed: 22-Aug-2016] I forgot there was a constant\literal ' , ' in the above expression, so that string-literal also would have to evaluate as a numeric to allow that expression with the + as addition-operator to function at run-time. But of course, that literal could never be interpreted as a numeric; so while the expression could be treated as valid for compile-time [with implicit cast in effect and data-checking not examining the literal value], that expression never would be capable of being evaluated at run-time.
Therefore, if the || operator was properly coded [as seems so, given what was claimed to have been "tried"], yet did not effect what was desired, then the OP would need to be updated to state exactly what was the problem. For example, perhaps there was an error in compile\CREATE of the routine, or perhaps a run-time error for which the effect of the concatenation was perhaps untrimmed results or some other unexpected output, or something else.?.?
Note: as I already added in a comment to a prior answer, the use of CONCAT operator vs the equivalent || in SQL source enables use of that source in\across other code pages without a possible issue due to the use of a variant character.
p.s. A CASE statement might be preferred in place of the IF\ELSE constructs
p.p.s. Might be worth review if the SP really should return both the RS and, or just, the OUT parameters
String concatenation can be done with the || operator.
set vEmail = userName || '#' || domain || '.' || tld;
Give that a try.
I am currently coding a Delphi 7 program that utilises SQL and an Access 2003 database.
The unit receives a 5 digit code from a previous unit, via a public variable (this is frmLogin.sCode). On form activation, the program will execute an SQL query to display the record from tblStudents that matches sCode. This statement uses a ParamByName line and works perfectly.
If no match is found, a message is displayed and the user is left with no option, but to click on the add user button. The user is then prompted to enter all of his details into the program, which are then passed to a class which sets out the SQL Insert Statement. A problem occurs now, however, as a message is displayed stating that Parameter Username is not found. I cannot understand why, as it is found when the Select statement is run. Please could someone help with this?
procedure TfrmProfilePage.FormActivate(Sender: TObject);
begin
//Instantiates the object.
objProfilePage := TProfilePage.Create;
sSQL := objProfilePage.SelectSQL;
ExecuteSQL(sSQl);
end;
procedure TfrmProfilePage.ExecuteSQL(sSQL : String);
begin
With dmTextbookSales do
Begin
dbgrdDisplay.DataSource := dsProfilePage;
qryProfilePage.SQL.Clear;
qryProfilePage.SQL.Add(sSQL);
qryProfilePage.Parameters.ParamByName('Username').Value := frmLogin.sCode;
qryProfilePage.Open;
If qryProfilePage.RecordCount = 0
Then
Begin
ShowMessage('Please click on the "Add Details" button to get started.');
btnChange.Enabled := False;
btnSelling.Enabled := False;
btnBuying.Enabled := False;
End;
End;
end;
procedure TfrmProfilePage.GetValues(VAR sStudentName, sStudentSurname, sCellNumber, sEmailAddress : String; VAR iCurrentGrade : Integer);
begin
ShowMessage('Fields may be left blank, but users wishing to sell textbooks should enter at least one contact field.');
sStudentName := InputBox('Name','Please enter your first name:','');
sStudentSurname := InputBox('Surame','Please enter your surname:','');
iCurrentGrade := StrToInt(InputBox('Current Grade','Please enter your current grade:',''));
sCellNumber := InputBox('Cellphone Number','Please enter your cellphone number:','');
sEmailAddress := InputBox('Email Address','Please enter your email address:','#dainferncollege.co.za');
end;
procedure TfrmProfilePage.btnAddClick(Sender: TObject);
begin
GetValues(sStudentName, sStudentSurname, sCellNumber, sEmailAddress, iCurrentGrade);
sSQL := objProfilePage.InsertSQL;
ExecuteSQL(sSQL);
btnChange.Enabled := True;
btnSelling.Enabled := True;
btnBuying.Enabled := True;
end;
The following code is obtained from the linked class, clsProfilePage:
function TProfilePage.InsertSQL: String;
begin
Result := 'INSERT INTO tblStudents (' + '[StudentID]' + ',' + '[StudentName]' + ',' + '[StudentSurname]' + ',' + '[CurrentGrade]' + ',' + '[CellNumber]' + ',' + '[EmailAddress]' + ') VALUES (' + 'Username' + ',' + QuotedStr(fStudentName) + ',' + QuotedStr(fStudentSurname) + ',' + IntToStr(fCurrentGrade) + ',' + QuotedStr(fCellNumber) + ',' + QuotedStr(fEmailAddress) + ')';
end;
function TProfilePage.SelectSQL: String;
begin
Result := 'SELECT * FROM tblStudents Where StudentID = Username';
end;
Your INSERT statement is wrong. You need to add parameters before you can set parameter values. In Delphi, you do that using : before the parameter name in your SQL statement.
In addition, Open is only used when performing a SELECT. INSERT, UPDATE, and DELETE don't return a rowset, and therefore you must use ExecSQL (the dataset method, not your function with the conflicting name) instead.
(While we're at it, never use RecordCount on a SQL dataset - it requires all rows to be retrieved in order to obtain a count, and it's not relevant when performing anything other than a SELECT anyway. Operations performed by ExecSQL should use RowsAffected instead, which tells you the number of rows that were affected by the operation.
(If you need a count of the number of rows, perform a SELECT COUNT(*) AS NumRecs FROM YourTable WHERE <some condition> instead, and access the NumRecs field using FieldByName.)
Change your function that returns the INSERT statement to something like this (the #13 in Result is a carriage return, which prevents having to manually insert spaces at the end of each line to separate SQL words):
function TProfilePage.InsertSQL: String;
begin
Result := 'INSERT INTO tblStudents ([StudentID],'#13 +
'[StudentName], [StudentSurname],'#13 +
'[CurrentGrade], [CellNumber], [EmailAddress])'#13 +
'VALUES (:Username, :StudentName,'#13 +
':StudentSurname, :CurrentGrade,'#13 +
':CellNumber, :EMailAddress)';
end;
You can then use it with ParamByName, without jumping through all of the hoops with QuotedStr and concatenation:
procedure TfrmProfilePage.AddUser;
begin
with dmTextbookSales do
begin
qryProfilePage.SQL.Text := InsertSQL;
qryProfilePage.Parameters.ParamByName('Username').Value := frmLogin.sCode;
qryProfilePage.Parameters.ParamByName('StudentName').Value := frmLogin.sUserName;
// Repeat for other parameters and values - you have to set every
// single parameter. To skip, set them to a null variant.
// Execute the INSERT statement
qryProfilePage.ExecSQL;
// See if row was inserted, and do whatever.
If qryProfilePage.RowsAffected > 0 then
ShowMessage('User added successfully');
// Perform a SELECT to populate the grid contents with the new
// rows after the update
end;
end;
I'd highly suggest you rethink this code. It's extremely convoluted, and it requires too much to accomplish a simple task (adding a new user).
If it were me, I'd use a separate query that was dedicated only to performing the INSERT operation, where you can set the SQL at design-time, and set the proper types for the parameters in the Object Inspector. Then at runtime, you simply set the parameter values and call ExecSQL on that insert query, and refresh your SELECT query to reflect the new row. It avoids all of the noise and clutter (as well as some unnecessary function calls and convoluted SQL building, opening and closing your SELECT query, etc.).
(It would also allow you to remove that horrific with statement, which leads to hard-to-find bugs and difficult to maintain code.)
You also have some bad linkages between forms, where you're referencing frmLogin (a specific form instance) from a second form. This means that you can never have more than one instance of either form in use at the same time, because you've hard-coded in that reference. I'd rethink that to use either parameters passed in when you create the form, or as properties that are set by the login form when creating the profile page form (or whatever TProfilePage is - your post doesn't say).
The best solution would be to move all of the non-UI related code into a separate unit (such as a TDataModule, which is designed to be used to work with non-visual components such as ADO queries) and remove it from the user-interface related forms anyway, which
Eliminates the coupling between forms, allowing the code to be reused.
Removes the non-visual data related components from cluttering the form and form code.
Separates the business logic (the part not related to interacting with the user) in a separate, distinct location, making it (and the code that uses it) easier to maintain.
Your insert statement is wrong. You need to replace the value for [StudentID].
'INSERT INTO tblStudents ('
+ '[StudentID]' + ','
+ '[StudentName]' + ','
+ '[StudentSurname]' + ','
+ '[CurrentGrade]' + ','
+ '[CellNumber]' + ','
+ '[EmailAddress]' + ')
VALUES ('
+ 'Username' + ',' // <-- UserName will never be replaced by a QuotedStr
// Access is looking for a column with the name
// 'UserName' which can not be found
+ QuotedStr(fStudentName) + ','
+ QuotedStr(fStudentSurname) + ','
+ IntToStr(fCurrentGrade) + ','
+ QuotedStr(fCellNumber) + ','
+ QuotedStr(fEmailAddress) + ')';
I have the following code which is constructs an SQL statement based on a number of variables:
SQL.Add('SELECT CDbl(Answer) as An FROM v_Outcomes_FirstLastOneYear ' +
'WHERE ' + GetTool(ReportGrid.Cells[col, 0]) + ' ' +
'AND (Collector = ' + QuotedStr('Patient') + ') ' +
'AND (Question=' + GetQuestion(ReportGrid.Cells[col, 0]) + ') ' +
'AND (Answer is not null) ' +
'AND (Answer <> ''null '') ');
if Copy(ReportGrid.Cells[col, 0], Length(ReportGrid.Cells[col, 0]), 1) = '1' then
SQL.Add('AND ('+GetTPoint(first)+') ')
else
SQL.Add('AND ('+GetTPoint(second)+') ');
SQL.Add('ORDER BY CDbl(Answer)');
The top row of ReportGrid (a TStringGrid) has already been populated with a series of strings such as 'Peds phys 1', or 'Peds phys 2'. The last number is either 1 or 2.
The variables 'first' and 'second' a strings defined further up.
col is an integer - this statement is constructed as part of a for loop which goes through each of the columns and populates each row with data corresponding to the header.
GetTool(), GetQuestion() and GetTPoint() are functions I have defined. The code for GetTPoint() is as follows:
function GetTPoint(timepoint: string): string;
begin
if (timepoint = '0') or (timepoint = 'discharge') then
begin
if timepoint = '0' then
Result := 'FirstAxData=''TRUE'' and DischargeData=''FALSE''';
if timepoint = 'discharge' then
Result := 'DischargeData=''TRUE'' and FirstAxData=''FALSE''';
end
else
begin
timepoint := FormatFloat('0', StrToInt(timepoint)*30.4368);
Result := '[Date] BETWEEN ([Date of First CPC]+' + timepoint +
')-61 AND ([Date of First CPC]+'+timepoint+')+61';
end;
end;
Each of the custom functions are similar and simply returns a string. GetTool() and GetQuestion() both work fine but GetTPoint() throws the following compiler error:
E2010 Incompatible types: 'string' and 'procedure, untyped pointer or
untyped parameter'
Does anyone know why this is being thrown?
The code you've shown appears inside a with statement for the query object you're operating on. Something like this:
with SomeQuery do begin
SQL.Add(...);
...
end;
You're able to refer to the SQL property alone like that because the with statement brings the query object's members into the current scope. That means all its members, including the First method (used for selecting the first query result). Anything introduced in the scope of the with statement will hide things of the same name introduced in earlier scopes. That includes the first variable you say was declared elsewhere.
When you have the expression GetTPoint(first), the compiler interprets the name first as referring to the query method, not the variable. The method is not a string, and calling it doesn't return a string, so the compiler rightfully complains.
The best solution is to stop using with. It just introduces brittleness to code. If you simply must continue using with, then rename your first variable so it doesn't interfere with names brought into scope later. There is no way to refer to local variables that have been hidden by another scope. (If first were global, you could qualify it with the name of the unit, but global variables should be avoided almost as much as with statements.)