My problem is that I would like to make an append query in Ms-Access 2010. I tried to realize it in query designer, but it throws an error:
Type mismatch in expression
See the generated code below:
INSERT INTO Yield ( ProcessName, Sor, Lot,
ProcessCode, Outgoing, DefectReason, DefectQty, ModifyQty )
SELECT Process.[ProcessName], Sor.[Sor], Qty.[Lot], Qty.[ProcessCode],
Qty.[Outgoing Date], Qty.[Defect Reason], Qty.[Defect Qty], Qty.[Modify_Qty]
FROM (Sor INNER JOIN ProcessCode ON Sor.[SorID] = ProcessCode.[SorID])
INNER JOIN (Process INNER JOIN Qty ON Process.[ProcessID] = Qty.[ProcessID])
ON ProcessCode.[ProcessID] = Process.[ProcessID];
The tables and the attributes are all existing. The ID numbers are indexes, the Quantities are numerical, the 'ProcessName', 'Sor', 'Lot', 'ProcessCode', 'DefectReason' attributes are strings.
What could be the problem?
Thanks in advance.
Looks ok. The best advice is divide it in smaller pieces.
http://importblogkit.com/2015/05/how-do-you-eat-an-elephant/ .
Try this:
Remove the insert part. Just try the select to make sure the join are working properly. If this fail the problem is on the join fields
Then, Put the insert again, but instead of putting table fields from the SELECT use default values. '' for strings and 0 for numeric and put the right alias for column name. That way you make sure your data is bringing the right data type. If this fail then one of the field isnt really a string or a number. Like gustav suggest probably a DATE
If that work then try to put one table field each time until you find the one causing the problem. Maybe one field doesnt support null or is receiving a bigger value than supported.
The problem was that the Yield table did not have the listed attributes. I thought that if some of the listed output attributes are not included in the output table, Access automatically creates the missing new attributes. I was wrong. The output table has to contain the attributes (rows), new attributes cannot be inserted into it this way.
Related
I'm on a db2 database over as400 system.
I have a select query that is throwing the error in the title: SQL0802 code 6 which is "invalid numeric data" (translated).
I have tried separating the query in different parts and testing each part one by one to see if it works, I am 99% convinced that the problem comes because of a "CAST" clause I am using in a subquery(to cast CHAR to INT), I just don't understand why the subquery works by itself but it doesn't work as a part of the main query.
So if I run the subquery with the "CAST" clause it works fine, but when I run the main query that uses the subquery it doesn't work and the error arises.
Main query can be divided in 2 queries, see the code below.
query1 looks something like this:
select SUM(Price) from TABLE1
where X = 1
group by Country
having SUM(Price) = (query2);
query2 looks something like this:
SELECT SUM(UnitPrice * AmountStocked)
FROM TABLE2
WHERE J = X and ItemNumber in (
SELECT CAST(ItmNumbr AS INT) from TABLE3
where Id in (select Id from TABLE4 where Z=Y)
)
Notes:
*query2 will return a single number.
*Running query2 by itself works fine.
*Running query1 without the "having" clause works fine too.
*If I substitute the "SELECT CAST..." subquery in query2 with something like "(2002, 9912, 1234)" and then run the main query it works fine, so this pretty much confirms that the problem is the "CAST" clause.
*I have to CAST ItmNumbr to INT because ItemNumber is of Numeric type and
ItmNumbr is of Char type.
You said:
*I have to CAST ItmNumbr to INT because ItemNumber is of Numeric type and ItmNumbr is of Char type.
But this is not true. You could cast the other way around:
SELECT SUM(UnitPrice * AmountStocked)
FROM TABLE2
WHERE J = X and CHAR(ItemNumber) in (
SELECT TRIM(ItmNumbr) from TABLE3
where Id in (select Id from TABLE4 where Z=Y)
)
The advantage here is that non-numeric characters in ItmNumber will not blow you up, and CHAR(ItemNumber) should also not fail.
One thing to know about DB2 for i is that there are two ways to create database tables, and the two differ slightly in the characteristics of the resulting table. If the table is created using DDL (CREATE TABLE ...), then that table cannot contain bad data. The data types are verified on write, no matter how you write the data, it is validated before being written to the table. If the table is created by DDS (CRTPF ...), the table can indeed contain bad data because the data is not validated until it is read and loaded into a variable. Old style programs that write data to DDS tables by writing a record from a program described data structure are able to put whatever they want into a DDS defined table, including numeric data in character fields or worse, character data in numeric fields. This usually is only found in very old databases that have been migrated from the System/36 (circa 1980's) which used flat files rather than database files (it had no notion of a database). I only posit this because it is possible. Check the data in your file using hex() to see if there is anything funky in the ItmNumbr or ItemNumber fields.
I am not sure but I am thinking the issue has to do with your join of "WHERE J = X" since we don't know what "J" is and it may not join to "X" (not the correct data type).
Based on your analysis:
"*If I substitute the "SELECT CAST..." subquery in query2 with something like "(2002, 9912, 1234)" and then run the main query it works fine, so this pretty much confirms that the problem is the "CAST" clause."
Check the content of TABLE3.ItmNumbr. If it is defined as NUMERIC (unpacked decimal) it may contain non-numeric values (typically spaces). That may be causing the error you are observing.
first off, noob alert! :))
I need to construct a query that runs on many tables. The tables vary on name just on the last digits as per client code. The thing is, the values that change aren't sequential so looping as in i=1,2,3,... does not work. A possible solution would be to have those values on a given field on an other table.
Here is the code for the first two clients 015 and 061. The leading zero(s) must are essential.
SELECT LnMov2017015.CConta, RsMov2017015.DR, RsMov2017015.NInt, "015" AS CodCli
FROM LnMov2017015 INNER JOIN RsMov2017015 ON LnMov2017015.NReg = RsMov2017015.NReg
WHERE (((LnMov2017015.CConta)="6" And (LnMov2017015.CConta)="7") AND ((RsMov2017015.DR)=9999))
UNION SELECT LnMov2017061.CConta, RsMov2017061.DR, RsMov2017061.NInt, "061" AS CodCli
FROM LnMov2017061 INNER JOIN RsMov2017061 ON LnMov2017061.NReg = RsMov2017061.NReg
WHERE (((LnMov2017061.CConta)="6" And (LnMov2017061.CConta)="7") AND ((RsMov2017061.DR)=9999))
...
So for the first SELECT the table Name is LnMov2017015, the ending 015 being the value, the client code, that changes from table to table e.g. in the second SELECT the table name is LnMov2017061 (061) being what distinguishes the table.
For each client code there are two tables e.g. LnMov2017015 and RsMov2017015 (LnMov2017061 and RsMov2017061 for the second set client shown).
Is there a way that I can build the SQL, based upon the example SQL above?
Does anyone have an idea for a solution? :)
Apparently it is possible to build a query object to read data in another db without establishing table link. Just tested and to my surprise it works. Example:
SELECT * FROM [SoilsAgg] IN "C:\Users\Owner\June\DOT\Lab\Editing\ConstructionData.accdb";
I was already using this structure in VBA to execute DELETE and UPDATE action statements.
Solution found :)
Thank you all for your input.
Instead of linking 100 tables (password protected), I'll access them with SLQ
FROM Table2 IN '' ';database=C:\db\db2.mdb;PWD=mypwd'
And merge them all with a query, before any other thing!
I want to append new rows to a table-1 d:\dl based on the equality constraint lower(rdl.subdir) = lower(tr.n1), where rdl and tr would be prospective aliases for f:\rdl and f:\tr tables respectively.
I get a function name is missing ). message when running the following command in VFP9:
INSERT INTO d:\dl SELECT * FROM f:\rdl WHERE (select LOWER(subdir)FROM f:\rdl in (select LOWER(n1) FROM f:\tr))
I am using the in syntax, instead of the alias based equality statement lower(rdl.subdir) = lower(tr.n1) because I do not know where to define aliases within this command.
In general, the best way to get something like this working is to first make the query work and give you the results you want, and then use it in INSERT.
In general, in SQL commands you assign aliases by putting them after the table name, with or without the keyword AS. In this case, you don't need aliases because the ones you want are the same as the table names and that's the default.
If what you're showing is your exact code and you're running it in VFP, the first problem is that you're missing the continuation character between lines.
You're definitely doing too much work, too. Try this:
INSERT INTO d:\dl ;
SELECT * ;
FROM f:\rdl ;
JOIN f:\tr ;
ON LOWER(rdl.subdir) = LOWER(tr.n1)
I have a query in MS Access which creates a table from two subqueries. For two of the columns being created, I'm dividing one column from the first subquery into a column from the second subquery.
The datatype of the first column is a double; the datatype of the second column is decimal, with scale of 2, but I want the second column to be a double as well.
Is there a way to force the datatype when creating a table through a standard make-table Access query?
One way to do it is to explicitly create the table before putting anything into it.
Your current statement is probably like this:
SELECT Persons.LastName,Orders.OrderNo
INTO Persons_Order_Backup
FROM Persons
INNER JOIN Orders
ON Persons.P_Id=Orders.P_Id
WHERE FirstName = 'Alistair'
But you can also do this:
----Create NewTable
CREATE TABLE NewTable(FirstName VARCHAR(100), LastName VARCHAR(100), Total DOUBLE)
----INSERT INTO NewTableusing SELECT
INSERT INTO NewTable(FirstName, LastName, Total)
SELECT FirstName, LastName,
FROM Person p
INNER JOIN Orders o
ON p.P_Id = o.P_Id
WHERE p.FirstName = 'Alistair'
This way you have total control over the column types. You can always drop the table later if you need to recreate it.
You can use the cast to FLOAT function CDBL() but, somewhat bizarrely, the Access Database Engine cannot handle the NULL value, so you must handle this yourself e.g.
SELECT first_column,
IIF(second_column IS NULL, NULL, CDBL(second_column))
AS second_column_as_float
INTO Table666
FROM MyTest;
...but you're going to need to ALTER TABLE to add your keys, constraints, etc. Better to simply CREATE TABLE first then use INSERT INTO..SELECT to populate it.
You can use CDbl around the columns.
An easy way to do this is to create an empty table with the correct field types and then to an Append-To query and Access will automatically convert the data to the destination field.
I had a similar situation, but I had a make-table query creating a field with NUMERIC datatype that I wanted to be short text.
What I did (and I got the idea from Stack) is to create the table with the field in question as Short Text, and at the same time build a delete query to scrub the records. I think it's funny that a DELETE query in access doesn't delete the table, just the records in it - I guess you have to use a DROP TABLE function for that, to purge a table...
Then, I converted my make-table query to an APPEND query, which I'd never done before... and I just added the running of the DELETE query to my process.
Thank you, Stack Overflow !
Steve
I add a '& ""' to the field I want to make sure are stored as text, and a ' *1 ' (as in multiplying the amount by 1) to the fields I want to store as numeric.
Seems to do the trick.
To get an Access query to create a table with three numeric output fields from input numeric fields, (it kept wanting to make the output fields text fields), had to combine several of the above suggestions. Pre-establish an empty output table with pre-defined output fields as integer, double and double. In the append query itself, multiply the numeric fields by one. It worked. Finally.
I have the same copy of access running in 3 cities right now. They work perfectly ok. They are 99% the same with one minor difference. Each of them has two views which use different odbc connection to different cities DB (all these databases are SQL Server 2005). The views act as datasource for some two very simple queries.
However, while I tried to make a new copy for a new city, I found that one of the simple internal query returns the correct number of row but all data are empty while the other query functions correctly.
I checked the data of these two views, the data is correct.
The one causing problem are like
Select * from View_Top where Name = "ABC"
when the recordset returns, even rs!Name give me an empty string.
Please help
Well the query looks a little wrong to me, try using ' instead of " to delimit your ABC string...
Without the definition of VIEW_TOP it's hard to tell where your error is, but if you're getting rows but the columns are NULL I'm guessing that VIEW_TOP (or something it depends on) includes an OUTER JOIN and you're pulling the columns from the wrong side of the JOIN.
SELECT
acc.FIRM,
acc.OFFICE,
acc.ACCOUNT,
a.CONV_CODE,
a.OTHER_AMT AS AMOUNT,
a.TRANS_DATE,
a.DESCRIPTN,
a.JRNAL_TYPE
FROM AccTrans AS a LEFT OUTER JOIN ACC AS acc ON a.ACCNT_CODE = acc.ACCNT_CODE
WHERE
(acc.SUN_DB = 'IF1') AND
(ANAL_T0 <> '') AND
(a.TRANS_DATE < '20091022') AND
(a.JRNAL_TYPE = 'MATCH');
This is the definition of the view. Indeed, in Access i am able to view the result of this query, it has data. that's why i know the recordset returns the correct number of row (by counting the loop in the code). sorry for my mistakes, i use Account in the where clause, the select statements should be like
select Firm, Office, Account, Trans_Date.... from
view_top
where account = 'ABC'
the query returns the right number of row but all row data (even the account field) are empty string.
then i found out what really cause the problem is the AMOUNT field, if i omit the amount, everything works. though i don't understand why.
view_top definition
"Name, Account, AccountCode, Amount, Date...."
Select Statements:
Select Name, Account, AccountCode, Amount, Date
From View_Top Where Name = 'xxx'
I found that if I omit the Amount, everything works.
Though I still don't understand why.