I'm using Access 2003 (forced to do it due to retrocompatibility) to modify a 10 years old project, not made by me.
I encounter errors in executing this query:
INSERT INTO ClientiContratto ( ID, CLIENTE, DATA, PERIODO, IMPORTO, FATTURATO )
SELECT [Forms]![InserisciContratto]![Cliente] AS Espr1, (SELECT Nome from TAnagrafica WHERE TAnagrafica.IDAnagr = [Forms]![InserisciContratto]![Cliente]) AS Espr2, [Forms]![InserisciContratto]![Data] AS Espr3, [Forms]![InserisciContratto]![Periodo] AS Espr4, [Forms]![InserisciContratto]![Importo] AS Espr5, False AS Espr6;
That returns errors due to
(SELECT Nome from TAnagrafica WHERE TAnagrafica.IDAnagr = [Forms]![InserisciContratto]![Cliente]) AS Espr2
If I execute this query standalone, it works like a charm but when it comes to inserting the query into the INSERT INTO...SELECT statement, it returns (translated from italian):
Runtime error '3000': Reserved error (-3025): there are no messages
for this error.
The aim is to insert in a table some new values based on values found in the active form, and the part of code which isn't working should search into a table a value linked to the [InserisciContratto]![Cliente] actual value.
What am I doing wrong? Maybe is that because I cant execute a SELECT subquery in a previous SELECT query?
Any help would be appreciated.
You can work around the problem using a DLookUp instead of a subquery:
DLookUp("Nome", "TAnagrafica", "TAnagrafica.IDAnagr = [Forms]![InserisciContratto]![Cliente]")
Note that you can either use the DLookUp on a form control, or in a query. Both are valid. In the query, it'd look like this:
INSERT INTO ClientiContratto ( ID, CLIENTE, DATA, PERIODO, IMPORTO, FATTURATO )
SELECT [Forms]![InserisciContratto]![Cliente] AS Espr1, DLookUp("Nome", "TAnagrafica", "TAnagrafica.IDAnagr = [Forms]![InserisciContratto]![Cliente]") AS Espr2, [Forms]![InserisciContratto]![Data] AS Espr3, [Forms]![InserisciContratto]![Periodo] AS Espr4, [Forms]![InserisciContratto]![Importo] AS Espr5, False AS Espr6;
An alternate, common source of these kind of errors is that Access behaves finicky when using subqueries and not querying from a real table. You can easily work around that by using the subquery as the main query. Note that this does require the subquery to always return a result, else no row will be inserted:
INSERT INTO ClientiContratto ( ID, CLIENTE, DATA, PERIODO, IMPORTO, FATTURATO )
SELECT [Forms]![InserisciContratto]![Cliente] AS Espr1, Nome AS Espr2, [Forms]![InserisciContratto]![Data] AS Espr3, [Forms]![InserisciContratto]![Periodo] AS Espr4, [Forms]![InserisciContratto]![Importo] AS Espr5, False AS Espr6
FROM TAnagrafica
WHERE TAnagrafica.IDAnagr = [Forms]![InserisciContratto]![Cliente]
Related
I'm trying to create a query using the SQL SELECT statement but I keep getting a error with my code
This is my code:
SELECT *
FROM tblRegistration
WHERE (tblRegistration.InstanceID IN (
SELECT InstanceID FROM tblRegistration
SELECT tblCourse.InstanceID, tblCourse.HoursPerWeek
FROM tblCourse
WHERE (((tblCourse.HoursPerWeek)=40));
Access throws in far more parentheses in WHERE clause than are needed. Simplify by removing most of them then test. Access will eventually throw them back in if you switch builder between datasheet and design view and save the object. Always make sure brackets, parens, quote marks, and apostrophes are evenly paired.
Also have too many SELECT clauses.
Subquery for IN() must return only one field.
Consider:
SELECT *
FROM tblRegistration
WHERE tblRegistration.InstanceID IN (
SELECT tblCourse.InstanceID
FROM tblCourse
WHERE tblCourse.HoursPerWeek=40);
If you don't want to remove field from subquery, try:
SELECT *
FROM tblRegistration
WHERE EXISTS (
SELECT tblCourse.InstanceID, tblCourse.HoursPerWeek
FROM tblCourse
WHERE tblCourse.HoursPerWeek=40);
I am working on a query that will check the temp table if there is a record that do not exist on the main table. My query looks like this
SELECT * FROM [Telemarketing].[dbo].[PDCampaignBatch_temp]
WHERE [StartDateTime] NOT IN (SELECT [StartDateTime] FROM [Telemarketing].[dbo].PDCampaignBatch GROUP BY [StartDateTime])
but the problem is it does not display this row
even if that data does not exist in my main table. What seems to be the problem?
NOT IN has strange semantics. If any values in the subquery are NULL, then the query returns no rows at all. For this reason, I strongly recommend using NOT EXISTS instead:
SELECT t.*
FROM [Telemarketing].[dbo].[PDCampaignBatch_temp] t
WHERE NOT EXISTS (SELECT 1
FROM [Telemarketing].[dbo].PDCampaignBatch cb
WHERE t.StartDateTime = cb.StartDateTime
);
If the set is evaluated by the SQL NOT IN condition contains any values that are null, then the outer query here will return an empty set, even if there are many [StartDateTime]s that match [StartDateTime]s in the PDCampaignBatch table.
To avoid such issue,
SELECT *
FROM [Telemarketing].[dbo].[PDCampaignBatch_temp]
WHERE [StartDateTime] NOT IN (
SELECT DISTINCT [StartDateTime]
FROM [Telemarketing].[dbo].PDCampaignBatch
WHERE [StartDateTime] IS NOT NULL
);
Let's say PDCampaignBatch_temp and PDCampaignBatch happen to have the same structure (same columns in the same order) and you're tasked with getting the set of all rows in PDCampaignBatch_temp that aren't in PDCampaignBatch. The most effective way to do that is to make use of the EXCEPT operator, which will deal with NULL in the expected way as well:
SELECT * FROM [Telemarketing].[dbo].[PDCampaignBatch_temp]
EXCEPT
SELECT * FROM [Telemarketing].[dbo].[PDCampaignBatch]
In production code that is not a one-off, don't use SELECT *, write out the column names instead.
Most likely your issue is with the datetime. You may be only displaying a certain degree of percision like the year/month/date. The data may be stored as year/month/date/hour/minute/second/milisecond. If so you have to match down the the most granluar measurement of the data. If one field is a date and the other is a date time they also will likely never match up. Thus you always get no responses.
I would like to know if it's possible for expressions that are part of the SELECT statement list to be evaluated for rows not matching the WHERE clause?
From the execution order documented here, it seems that the SELECT gets evaluated long after the WHERE, however I ran into a very weird problem with a real-life query similar to the query below.
To put you in context, in the example, the SomeOtherTable has a a_varchar column which always contains numerical values for the code 105, but may contain non-numerical values for other codes.
The query statement works:
SELECT an_id, an_integer FROM SomeTable
UNION ALL
SELECT an_id, CAST(a_varchar AS int)
FROM SomeOtherTable
WHERE code = 105
The following query complains about being unable to cast a_varchar to int:
SELECT 1
FROM (
SELECT an_id, an_integer FROM SomeTable
UNION ALL
SELECT an_id, CAST(a_varchar AS int)
FROM SomeOtherTable
WHERE code = 105
) i
INNER JOIN AnotherOne a
ON a.an_id = i.an_id
And finally, the following query works:
SELECT 1
FROM (
SELECT an_id, an_integer FROM SomeTable
UNION ALL
SELECT
an_id,
CASE code WHEN 105 THEN CAST(a_varchar AS int) ELSE NULL END
FROM SomeOtherTable
WHERE code = 105
) i
INNER JOIN AnotherOne a
ON a.an_id = i.an_id
Therefore, the only explanation I could find was that with the JOIN, the query gets optimized differently in a way that CAST(a_varchar AS int) gets executed even if code <> 105.
The queries are run against SQL SERVER 2008.
Absolutely.
The documentation that you reference has a section called Logical Processing Order of the SELECT statement. This is not the physical processing order. It explains how the query itself is interpreted. For instance, an alias defined in the select clause cannot be references in the where clause, because the where clause is logically processed first.
In fact, SQL Server has the ability to optimize queries by doing various data transformation operations when it reads the data. This is a nice performance benefit, because the data is in memory, locally, and the operations can simply be done in place. However, the following can fail with a run-time error:
select cast(a_varchar as int)
from table t
where a_varchar not like '%[^0-9]%';
The filter is applied after the attempt at conversion, in the real process flow. I happen to consider this a bug; presumably, the folks at Microsoft do not think so, because they have not bothered to fix this.
Two workarounds are available. The first is try_convert(), which does conversions and returns NULL for a failure instead of a run-time error. The second is the case statement:
select (case when a_varchar not like '%[^0-9]%' then cast(a_varchar as int) end)
from table t
where a_varchar not like '%[^0-9]%';
I am retreiving values from a Table which in turn i am comparing with values from another table using the SQL keywords 'EXCEPT'
My query looks something like follows
SELECT DISTINCT TDC_TREE_FAMILY_CLASSIFICATION AS DPC_Level1,
TDC_TREE_CLASSIFICATION AS DPC_Level2,
TDC_TREE_SUB_CLASSIFICATION AS DPC_Level3
FROM TD_DATA_PACK_CONTENTS
EXCEPT
SELECT DPC_Level1,DPC_Level2,DPC_Level3 FROM DATA_PACK_CATEGORIES
ORDER BY DPC_Level1
Now this query works fine . What i want to do is save the results in a single string variable.
So I declare 3 temps variables to save the values of DPC_Level1,Lvl2,Lvl3 and then i can join them into a single string variable.
So i modify my Query like this.
SELECT DISTINCT #m_DPC_Level11=TDC_TREE_FAMILY_CLASSIFICATION AS DPC_Level1
,#m_DPC_Level2=TDC_TREE_CLASSIFICATION AS DPC_Level2,
,#m_DPC_Level13=TDC_TREE_SUB_CLASSIFICATION AS DPC_Level3
FROM TD_DATA_PACK_CONTENTS
EXCEPT
SELECT DPC_Level1,DPC_Level2,DPC_Level3 FROM DATA_PACK_CATEGORIES
ORDER BY DPC_Level1
But this throws the error
'A SELECT statement that assigns a value to a variable must not be
combined with data-retrieval operations'
. How i resolve this issue. I am using SQL Server 2008
I would go for a subquery
select #m_DPC_LEvel11 = DPC_Level1,
#m_DPC_Level2 = DPC_Level2,
#m_DPC_Level13 = DPC_Level3,
FROM
(SELECT DISTINCT TDC_TREE_FAMILY_CLASSIFICATION AS DPC_Level1,
TDC_TREE_CLASSIFICATION AS DPC_Level2,
TDC_TREE_SUB_CLASSIFICATION AS DPC_Level3
FROM TD_DATA_PACK_CONTENTS
EXCEPT
SELECT DPC_Level1,DPC_Level2,DPC_Level3 FROM DATA_PACK_CATEGORIES
ORDER BY DPC_Level1) s
select * into #transacTbl from tmpTrans
insert
select
(case when tmpT.TranStatus = 10
then(
select ID, 'Returned')
else(
select ID, 'GoodSale')
end)
from
(
select * from MainTransacSource
) as tmpT
I want to be able to insert the details of a transaction into a different table with a label if it is a returned or good sale/transaction. I did this to avoid the cursor so please avoid giving a solution using a cursor.
I know the code looks good but what I'm experiencing is that, the case statement only returns one value via subquery.
This is a simplified version of the code; I have at least 6 types of cases and should be able to insert by ROW. I hate to think that I have to repeat each case per column because the actual number of columns is about 38.
You may suggest another work-around if this doesn't fit the logic. Of course, without a cursor.
Without access to your tables and not knowing more about what precisely you want to acheive, try something like this:
select * into #transacTbl from tmpTrans
insert
select tmpT.ID,
(case when tmpT.TranStatus = 10
then 'Returned'
else 'GoodSale'
end)
from
(select * from MainTransacSource) as tmpT <OR simply MainTransacSource tmpT (maybe)>
Cheers.