Your immediate problem is that the old proprietary :UPDATE.. FROM.. does not work; it has cardinality problems. Good SQL programmers use the MERGE statement and have correct DDL so there are no cardinality errors,
You did not post any DDL (very rude!), so we cannot help you with your real problem. You are not writign SQL! This is COBOL programming done with SQL.
We have a DATE data type so all that string manipulation just mimics a 1950's COBOL program, with that silly default fifty character size. The local variables are also bad programming; those mimic COBOL local variables instead of SQL expressions We also do not use flags in SQL; that was assembly language.
Cleaning up your data elements a bit, you wrote this skeleton:
DECLARE @local_comp_date DATE,
@local_fiscal_code INTEGER;
SET @local_comp_date = CAST (CURRENT_TIMESTAMP AS DATE);
SET @local_fiscal_code
= (SELECT fiscal_code
FROM MFIfiscal_calendar
WHERE vague_date = @local_comp_date;
An SQL programmer would not waste time and space with @local_comp_date and use an expression:
DECLARE @local_fiscal_code INTEGER;
SET @local_fiscal_code
= (SELECT fiscal_code
FROM MFI_Fiscal_Calendar
WHERE vague_date = CAST (CURRENT_TIMESTAMP AS DATE);
now apply the same refactoring to @local_fiscal_code and so forth until you have removed all the local variables. This kind of pure SQL can be optimized. Your fake COBOL cannot
Did you look at that COBOL-style IF? The local variable is redundant.
IF @local_fiscal_code = 201109
BEGIN
UPDATE MFI_comp
SET units_sold_cnt = 0,
something_return_cnt = 0
WHERE store_code IN ('QY','QX','QU','TX')
AND fiscal_code = 201109 --- look at the IF!
AND check_cut_flag = 'N';
END;
This is the same as
UPDATE MFI_comp
SET units_sold_cnt = 0,
something_return_cnt = 0
WHERE store_code IN ('QY','QX','QU','TX')
AND fiscal_code = 201109 -- this is a constant here!
AND check_cut_flag = 'N';
Without DDL or specs we cannot help you. But what you did post looks pretty bad.
You did not post any DDL (very rude!), so we cannot help you with your real problem. You are not writign SQL! This is COBOL programming done with SQL.
We have a DATE data type so all that string manipulation just mimics a 1950's COBOL program, with that silly default fifty character size. The local variables are also bad programming; those mimic COBOL local variables instead of SQL expressions We also do not use flags in SQL; that was assembly language.
Cleaning up your data elements a bit, you wrote this skeleton:
DECLARE @local_comp_date DATE,
@local_fiscal_code INTEGER;
SET @local_comp_date = CAST (CURRENT_TIMESTAMP AS DATE);
SET @local_fiscal_code
= (SELECT fiscal_code
FROM MFIfiscal_calendar
WHERE vague_date = @local_comp_date;
An SQL programmer would not waste time and space with @local_comp_date and use an expression:
DECLARE @local_fiscal_code INTEGER;
SET @local_fiscal_code
= (SELECT fiscal_code
FROM MFI_Fiscal_Calendar
WHERE vague_date = CAST (CURRENT_TIMESTAMP AS DATE);
now apply the same refactoring to @local_fiscal_code and so forth until you have removed all the local variables. This kind of pure SQL can be optimized. Your fake COBOL cannot
Did you look at that COBOL-style IF? The local variable is redundant.
IF @local_fiscal_code = 201109
BEGIN
UPDATE MFI_comp
SET units_sold_cnt = 0,
something_return_cnt = 0
WHERE store_code IN ('QY','QX','QU','TX')
AND fiscal_code = 201109 --- look at the IF!
AND check_cut_flag = 'N';
END;
This is the same as
UPDATE MFI_comp
SET units_sold_cnt = 0,
something_return_cnt = 0
WHERE store_code IN ('QY','QX','QU','TX')
AND fiscal_code = 201109 -- this is a constant here!
AND check_cut_flag = 'N';
Without DDL or specs we cannot help you. But what you did post looks pretty bad.
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking in Sets / Trees and Hierarchies in SQL