Query runs on DB but throws exception in java - java

I'm having some trouble executing a nested sql query. It works fine when i run it on TOAD (for Oracle DB) but when I try and execute the same query from my java program it gives me an error : ORA-00923: FROM keyword not found where expected:
Here is the query:
Select *
from(select tb1.Number, tb1.Desc, tb1.Local, tb2.Division
from tb1
inner join tb2
on tb1.Number = tb2.Number
and Local in ('ENG_USA', 'ENG_CHINA', 'FR_FRENCH'))
where Number in ('7512','4706')
Like I mentioned, it executes fine on Toad and is able to retrieve data but the same query throws the ORA-00923 exception.
rset = stmt.executeQuery(Select *
from(select tb1.Number, tb1.Desc, tb1.Local, tb2.Division
from tb1
inner join tb2
on tb1.Number = tb2.Number
and Local in ("+loc+"))
where Number in ("+s+")
Reply With Quote


I had a similar issue with mysql. My problem was that i splitted the query in multiple rows without leaving a space between 2 rows.
So your query should be:
rset = stmt.executeQuery("Select * from(select tb1.Number, tb1.Desc, tb1.Local, tb2.Division from tb1 inner join tb2 on tb1.Number = tb2.Number and Local in ("+loc+")) where Number in ("+s+")"
PS: I would like to write this as a comment but for some reason i can't in this question. Sorry!


First off, I don't see the beginning or ending double-quotes in your Java code. Since your Java code must compile in order to get far enough to receive an Oracle error, I'm assuming that there is a double quote prior to the SELECT, a double-quote after the final close paren, and then another close parent to match to the open paren on the executeQuery. So I'm assuming that your actual code is something like
rset = stmt.executeQuery(
"Select *
from(select tb1.Number, tb1.Desc, tb1.Local, tb2.Division
from tb1
inner join tb2
on tb1.Number = tb2.Number
and Local in ("+loc+"))
where Number in ("+s+")");
Is there a reason that you're building the SQL statement dynamically rather than using bind variables? Using bind variables is more secure since you don't need to worry about SQL injection attacks. It is more efficient since you're not forcing the database to hard parse the query every time. And it saves you from many sorts of errors around quoting and escaping. In your case, assuming that the local variable loc does not have the leading and trailing single quotes, you'd need to include those in your query
rset = stmt.executeQuery(
"Select *
from(select tb1.Number, tb1.Desc, tb1.Local, tb2.Division
from tb1
inner join tb2
on tb1.Number = tb2.Number
and Local in ('"+loc+"'))
where Number in ("+s+")");
Had you used bind variables and just bound loc to the first bind variable, on the other hand, you wouldn't need to worry about adding the single quotes (or escaping any single quotes in loc.

Related

Why does my code produce the error: The statement did not return a result set [duplicate]

This question already has answers here:
Execute "sp_msforeachdb" in a Java application
(3 answers)
Closed 1 year ago.
I am executing the following query from Microsoft SQL Server Studio, which works fine and displays results:
SELECT *
INTO #temp_table
FROM md_criteria_join
WHERE user_name = 'tecgaw'
UPDATE #temp_table
SET user_name = 'tec'
WHERE user_name != 'tec'
SELECT *
FROM md_criteria_join
WHERE user_name = 'tec'
AND view_name NOT IN (SELECT view_name
FROM md_criteria_join
WHERE user_name = 'tecgaw')
UNION
SELECT *
FROM #temp_table
ORDER BY view_name,
user_name,
crit_usage_seq,
crit_join_seq
However, if I execute the same query in Java, an Exception is thrown stating
The statement did not return a result set.
Here's the Java code:
statement = conn.getConnection().createStatement();
resultSet = stmt.executeQuery(sql.toString());
Is that because I cannot do multiple SQL queries in one statement (I.e., Creating the #temp_table, updating it, and then using for it my select statement)?

JDBC is getting confused by row counts.
You need to use SET NOCOUNT ON.

Use execute statement for data manipulation like insert, update and delete and
executeQuery for data retrieval like select
I suggest you to separate your program into two statements one execute and one executeQuery.
If you do not wish to do that, try separating the statements with semi-colon. But I am not sure about this action if this gives you a resultset or not.

I have found similar question in StackOverflow here. You should enable connection to support multiple statements and separate them using ;. For concrete examples see that answer. However it is for MySql only.
Also I think you can rewrite your SQL into single query
SELECT columnA, columnB, 'tec' as user_name from md_criteria_join
WHERE (
user_name = 'tec'
AND view_name NOT IN (
SELECT view_name
FROM md_criteria_join
WHERE user_name = 'tecgaw')
)
OR user_name = 'tecgaw'
ORDER BY view_name, user_name, crit_usage_seq, crit_join_seq
Another option is to move your statements to stored procedure and ivoke it from JDBC using CallableStatement
Or maybe you should try executing it with multiple jdbc statements like this
Connection conn = conn.getConnection(); //just to make sure its on single connection
conn.createStatement("SELECT INTO #temp_table").executeUpdate();
conn.createStatement("UPDATE #temp_table").executeUpdate();
conn.createStatement("SELECT ...").executeQuery();
Note you have to close resources and maybe for better performance you could use addBatch and executeBatch methods

in ms sql you also have to do set nocount on right at the beginning of the stored procedure along with terminating select / update/ insert block statement with ";"

SQL Firebird implementation in java/ IBSQL

so tried to put that SQL code into my java-aplication:
SELECT DISTINCT
StRzImRo.Rohstoff, StRo.Bezeichnung,
CAST (SUM(BwLsImAt.Lieferungen * StRzImRo.Menge * StAt.PROD__REZEPTURGEWICHT / Coalesce(StRz.PARM__BEZUGSGROESSE,1)) AS NUMERIC (9,3)) Rohstoffverbrauch_Gesamt FROM BwLsImAt
JOIN StAt ON (StAt.IntRowId = BwLsImAt.Artikel)
JOIN StRz ON (StRz.IntRowId = StAt.PROD__REZEPTUR)
JOIN StRzImRo ON (StRzImRo.Master = StRz.IntRowId)
JOIN StRo ON (StRzImRo.Rohstoff = StRo.IntRowId)
WHERE StAt.IntRowId > 0
GROUP BY StRzImRo.Rohstoff, StRo.Bezeichnung
-- GROUP BY StRzImRo.Rohstoff, StRzImRo.Menge, StAt.PROD__REZEPTURGEWICHT, Coalesce(StRz.PARM__BEZUGSGROESSE,1)
The code is fully funcional and tested in IBSQL but not working in my java-application.
My app does work properly with other code. I get this error:
org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544569. Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, column 266
ON
I would be very happy if someone could help me with this problem. Thanks!
P.S.: Sorry for my bad language, but i´m not a native speaker

The error suggests there is an ON in an unexpected place in your query, and as the query itself looks fine, my guess is the problem is with the way you construct the query in your Java application. There might be some whitespace missing in your query.
My guess is that you have something like
query = "SELECT * " +
"FROM table1" +
"JOIN table2 ON " //.....
The missing whitespace will make the SQL:
SELECT * FROM table1JOIN table2 ON ....
For the parser, this is perfectly valid until it encounters the ON token, which triggers the error. Eg the parser identifies it is a SELECT with * (all) columns from table1JOIN with alias table2. During parsing the server doesn't check if the table actually exists, so it doesn't trip over the fact that table1JOIN doesn't exist. That is checked after parsing is successfully completed.

Which wildcard in SQL-Statement do I have to use for an Access *.mdb-file query (using Java & JDBC:ODBC bridge)

I try to execute the following SQL-Statement (in my Java-application):
SELECT * FROM Tbl_Job WHERE jobname LIKE '%aa%';
But I can't get the same (correct?) result using MS Access (2002):
SELECT * FROM Tbl_Job WHERE jobname LIKE '*aa*';
With this example Access will give me 400 datasets and my Java-application will only give me somewhat less I don't know the exact number of datasets.
I tried to use the [*]-wildcard in my Java-app but it didn't give me any datasets at all.
Besides I tried to replace the [']-character with the ["]-character but this didn't work either.
I don't know whether this is relevant or not but I think the *.mdb-file was created with MS Access (2000)
My Java code:
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection connection = DriverManager.getConnection("jdbc:odbc:_
Driver={Microsoft Access Driver_
(*.mdb)};DBQ=C:\database.mdb");
Statement stm = connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ResultSet rs = stm.executeQuery(sql);
while(rs.next())
do_some_stuff();

Suggest you try this SQL statement both from Java and directly in Access.
SELECT Count(*) AS num_rows FROM Tbl_Job WHERE jobname ALike '%aa%';
If num_rows is the same in both cases, change the WHERE clause in your first query to match this one.
If num_rows is not the same in both cases, please describe how they differ and which is correct.

SQL full join in Java

I'm trying to join two tables but can't get the SQL right. My SQL statement is far more complex than the below SQL but the below SQL will do to show the principle. I get an invalid identifier exception when trying to refer to t or p. How come I cannot refer to these? I'm using Oracle DB.
SQL:
SELECT * FROM ((SELECT * FROM transactions t) FULL JOIN (SELECT * FROM payments p) ON (t.id = p.trans_id));
Exception:
Caused by: java.sql.SQLException: ORA-00904: "P"."TRANS_ID": invalid identifier

You are not really giving your querys an alias, you should do:
SELECT *
FROM (SELECT * FROM transactions) t
FULL JOIN (SELECT * FROM payments) p
ON (t.id = p.trans_id);
Of course, assuming that you are using real derived tables instead of those simple SELECTs, otherwise you should just use the tables directly.

The aliases are in the wrong place. The alias for a derived table should be just after the closing parenthesis:
SELECT *
FROM
(SELECT * FROM transactions) t
FULL JOIN
(SELECT * FROM payments) p
ON t.id = p.trans_id
Note that it makes no sense to use derived tables with such a simple query. I assume that you do actually need the derived tables and that you just simplified your query for the question.

When should we use a PreparedStatement instead of a Statement?

I know the advantages of using PreparedStatement, which are
query is rewritten and compiled by the database server
protection against SQL injection
But I want to know when we use it instead of Statement?

Query is rewritten and compiled by the database server
If you don't use a prepared
statement, the database server will
have to parse, and compute an
execution plan for the statement
each time you run it. If you find
that you'll run the same statement
multiple times (with different
parameters) then its worth preparing
the statement once and reusing that
prepared statement. If you are
querying the database adhoc then
there is probably little benefit to
this.
Protected against SQL injection
This is an advantage you almost
always want hence a good reason to
use a PreparedStatement everytime.
Its a consequence of having to
parameterize the query but it does
make running it a lot safer. The
only time I can think of that this
would not be useful is if you were
allowing adhoc database queries; You
might simply use the Statement
object if you were prototyping the
application and its quicker for you,
or if the query contains no
parameters.

Ask Tom's opinion:
The use of a Statement in JDBC should be 100% localized to being used for DDL (ALTER,
CREATE, GRANT, etc) as these are the only statement types that cannot accept BIND
VARIABLES.
PreparedStatements or CallableStatements should be used for EVERY OTHER type of statement
(DML, Queries). As these are the statement types that accept bind variables.
This is a fact, a rule, a law -- use prepared statements EVERYWHERE. Use STATEMENTS
almost no where.
He's specifically talking about Oracle but the same principle applies to any database that caches execution plans.
Database apps that scale and prevent SQL injection attacks at the same time? What's the downside?

I would turn this round: in a publicly distributed app, you should generally always use prepared statements unless you have a really compelling reason not to, and you should always supply parameters "properly" to the prepared statement, and not by splicing them into the query string.
Why? Well, basically because of the reasons you gave (or at least, the second one)...

PreparedStatements should be used very carefully in WHERE clauses.
Suppose that a table is defined as:
create table t (int o, k varchar(100), v varchar(100))
(e.g. "o: object-ID (foreign key), k: attribute-key, v: attribute-value").
Furthermore there is a (non-unique) index on v.
create index ixt on t ( v )
Suppose that this table contains 200 million rows inserted like:
for (i = 0; i < 100*1000*1000; i++) {
insert into t (o,k,v) values (i,'k1','v1');
insert into t (o,k,v) values (i,'k2', Convert(i, varchar));
}
("Thus, every object o has attributes k1=v1 and k2=o")
Then you should not build queries like:
select o,p,v from t as tx, t as ty where tx.o=ty.o and tx.k=? and tx.v=? and ty.k=? and ty.v=?
("find objects that have two given attributes")
My experience with ORACLE and MSSQL is, that those queries might need many minutes to return. This is true even if no row matches the where clause. It depends on wether the SQL-Server decides to lookup tx.v or ty.v first.
One shoud put the values for the columns k and v directy into the statement. I think this is because the SQL-Servers take the values into account when computing the execution plan.
A query look like this returns always after milliseconds:
select o,p,v from t as tx, t as ty where tx.o=ty.o and tx.k='k1' and tx.v='v1' and ty.k='k2' and ty.v='1234'
("The SQL-Server will always search first for v='1234' and then for v='v1' ")
Regards
Wolfgang

Statement: Each time the sql query is running,this sql statement is sent to the DBMS where it is compiled. So, it increases the server loads and decreases the performance.
connection con=null;
String sql="select * from employee where id=5";
Statement st=conn.createStatement();
PreparedStatement: Unlike Statement PreparedStatement is given a sql query as a parameter when it is created.
connection con=null;
String sql="select * from employee where id=?";
PreparedStatement ps=conn.prepareStatement(sql);
This sql statement is sent to Database where it is compiled.
So,in preparedStatement compiled happens only once but in statement compiled happens each time Statement is called.

You can always use PreparedStatement instead of Statment( select, insert , update, delete ). Better performance and protected against SQL injection.
But, don't use it with a dynamic request like a request with WHERE variable IN [ hundreds possibilities ] :
It's counter-productive, you lost performance and memory because you cache every time a new request, and PreparedStatement are not just for SQL injection, it's about performance. In this case, Statement will not be slower.
Your pool have a limit of PreparedStatment ( -1 defaut but you must limit it ), and you will reach this limit ! and if you have no limit or very large limit you have some risk of memory leak, and in extreme case OutofMemory errors. So if it's for your small personnal project used by 3 users it's not dramatic, but you don't want that if you're in a big company and that you're app is used by thousand people and million request.
Some reading.
IBM : Periodical OutOfMemory errors with prepared statement caching

It's simply a Java DESIGN MISTAKE tie "prepared statement" with "parameterized query / bind variables".
Databases does have API to accept "bind variables" in SQL code that just run once time.
It's a big resource wasting force use "prepared statement" everywhere, just to protect from SQL injection. Why not Java just let developers use databases in correct way?
It could be as follows:
Statement Interface - Multiples commands could be run. Not accept bind variables. One execution of SQL command. No SQL injection protection.
PreparedStatement Interface - One command could be run. Accept bind variables.
Multiple executions of SQL command. SQL injection protection.
(MISSING IN JAVA!) RunOnceStatement - One command could be run. Accept bind variables. One execution of SQL command. SQL injection protection.
For exemple, in Postgres performance could be better, by driver mapping to:
Statement Interface - PQExec()
PreparedStatement Interface - PQPrepare() / PQExecPrepare() / ...
(MISSING IN JAVA!) RunOnceStatement - PQExecParams()
Using prepared statement in SQL code that runs just once is a BIG performance problem: more processing in database, waste database memory, by maintaining plans that will not called later. Cache plans get so crowed that actual SQL commands that are executed multiple times could be deleted from cache.

Besides preventing SQL injection, formatting portability (which you can't get from Statement), performance is the obvious reason. However, PreparedStatement doesn't come without any penalty. For example, it is generally slower than Statement if running only once, as there is some overhead. So the general idea is PreparedStatement should be used when you are performing the same query many many times. However, how much overhead is very database server implementation-specific, so exactly when to choose PreparedStatement over Statement, from performance consideration, should really be based on your actual experience/experiments of a specific database server.

I was facing the same issue ,Then I break the query into multiple common table expression (cte) and now it's working fine for me.
SELECT DISTINCT
1 AS RecordSource, --CMD
EA.EmployerKey,
EA.AccountID,
ISNULL(EA.SourceGroupNumber,'NA') AS SourceGroupNumber,
EA.SourceSubGroupNumber,
EA.PurchaserOrgNumber,
ISNULL(EA.GroupName,'NA') AS GroupName,
EA.MemberSourceCode,
CASE WHEN ESA.EmailAddress = '' OR ESA.EmailAddress IS NULL THEN 'UNKNOWN#UNKNOWN.COM'
ELSE ESA.EmailAddress END AS EmailAddress,
CASE WHEN ESA.FirstName='' OR ESA.FirstName IS NULL THEN 'NA' ELSE ESA.FirstName END AS FirstName,
CASE WHEN ESA.MiddleName='' OR ESA.MiddleName IS NULL THEN 'NA' ELSE ESA.MiddleName END AS MiddleInitial,
CASE WHEN ESA.LastName='' OR ESA.LastName IS NULL THEN 'NA' ELSE ESA.LastName END AS LastName,
CASE WHEN ESA.ContactName='' OR ESA.ContactName IS NULL THEN 'NA' ELSE ESA.ContactName END AS ContactName,
ISNULL(ESA.PhoneNumber,'NA') As PhoneNumber,
'NA' AS MobilePhoneNumber,
'GROUP ADMINISTRATOR' AS ContactType,
ESA.StateCode
INTO DCB_A1.Temp_abc
FROM
(SELECT FE.EmployerKey, DE.AccountID, DE.SourceGroupNumber, DE.SourceSubGroupNumber,DE.PurchaserOrgNumber,
DE.GroupName, DE.MemberSourceCode
FROM DCB_A1.FctESF FE
INNER JOIN DCB_A1.DimESF DE
ON FE.EmployerKey = DE.EmployerKey
LEFT JOIN DCB_A1.DimMKBU DM
ON FE.MBUKey = DM.MarketingBusinessUnitKey
where DE.IsActiveVersion = 1 AND DE.PurchaserOrgTerminationReasonCode <> '171'
--and (MBUStateCoverage <> '' and MBUStateCoverage <> 'UNK')
GROUP BY FE.EmployerKey, DE.AccountID, DE.SourceGroupNumber,DE.SourceSubGroupNumber,DE.PurchaserOrgNumber,
DE.GroupName, DE.MemberSourceCode
)EA
INNER JOIN
(SELECT DE.AccountID,DE.SourceGroupNumber,
DE.MemberSourceCode,DE.GroupName,
ISNULL(DC.ContactValue,'') AS EmailAddress,
ISNULL(DN.ContactText2,'') AS FirstName,
ISNULL(DN.ContactText3,'') AS MiddleName,
ISNULL(DN.ContactText4,'') AS LastName,
ISNULL(DN.ContactValue,'') AS ContactName,
ISNULL(DP.ContactValue,'') AS PhoneNumber,
SUBSTRING(MBUStateCoverage, 1, 2) AS StateCode
FROM DCB_A1.FctESF FE
INNER JOIN DCB_A1.DimESF DE
ON FE.EmployerKey = DE.EmployerKey
LEFT JOIN DCA_A1.DimECSF DC
ON DE.MemberSourceCode = DC.MemberSourceCode
AND DE.PurchaserOrgNumber = DC.PurchaserOrgNumber
AND DE.PurchaserOrgTypeCode = DC.PurchaserOrgTypeCode
AND DC.ContactType = 3
--and DC.ContactValue <> '' -- Do we need this?
LEFT JOIN DCA_A1.DimECSF DN
ON DE.MemberSourceCode = DN.MemberSourceCode
AND DE.PurchaserOrgNumber = DN.PurchaserOrgNumber
AND DE.PurchaserOrgTypeCode = DN.PurchaserOrgTypeCode
AND DN.ContactType = 4
AND DN.IsActiveVersion = 1
LEFT JOIN DCA_A1.DimECSF DP
ON DE.MemberSourceCode = DP.MemberSourceCode
AND DE.PurchaserOrgNumber = DP.PurchaserOrgNumber
AND DE.PurchaserOrgTypeCode = DP.PurchaserOrgTypeCode
AND DP.ContactType = 1
LEFT JOIN DCB_A1.DimMKBU DM
ON FE.MBUKey = DM.MarketingBusinessUnitKey
WHERE DE.IsActiveVersion = 2
--and DE.AccountID =2
--AND (DE.CustomerStatusCode = 'A'
-- OR DE.IsEmployerActive = 0)
----and CustomerStatusCode = 'A'
--AND (MBUStateCoverage <> '' and MBUStateCoverage <> 'UNK')
GROUP BY DE.AccountID,DE.SourceGroupNumber,
DE.MemberSourceCode,DE.GroupName,
ISNULL(DC.ContactValue,''), ISNULL(DN.ContactValue,''),
ISNULL(DN.ContactText2,''),ISNULL(DN.ContactText3,''),
ISNULL(DN.ContactText4,''),ISNULL(DP.ContactValue,'') ,SUBSTRING(MBUStateCoverage, 1, 2)
)ESA
ON EA.AccountID = ESA.AccountID ;
[Amazon][JDBC](11220) Parameters cannot be used with normal Statement objects, use PreparedStatements instead.`
****Below check what I done with this code and it iss now working fine.****
with ESA AS
(SELECT DE.AccountID,DE.SourceGroupNumber,
DE.MemberSourceCode,DE.GroupName,
ISNULL(DC.ContactValue,'') AS EmailAddress,
ISNULL(DN.ContactText2,'') AS FirstName,
ISNULL(DN.ContactText3,'') AS MiddleName,
ISNULL(DN.ContactText4,'') AS LastName,
ISNULL(DN.ContactValue,'') AS ContactName,
ISNULL(DP.ContactValue,'') AS PhoneNumber,
SUBSTRING(MBUStateCoverage, 1, 2) AS StateCode
FROM DCB_A1.FctESF FE
INNER JOIN DCB_A1.DimESF DE
ON FE.EmployerKey = DE.EmployerKey
LEFT JOIN DCA_A1.DimECSF DC
ON DE.MemberSourceCode = DC.MemberSourceCode
AND DE.PurchaserOrgNumber = DC.PurchaserOrgNumber
AND DE.PurchaserOrgTypeCode = DC.PurchaserOrgTypeCode
AND DC.ContactType = 3
--and DC.ContactValue <> '' -- Do we need this?
LEFT JOIN DCA_A1.DimECSF DN
ON DE.MemberSourceCode = DN.MemberSourceCode
AND DE.PurchaserOrgNumber = DN.PurchaserOrgNumber
AND DE.PurchaserOrgTypeCode = DN.PurchaserOrgTypeCode
AND DN.ContactType = 4
AND DN.IsActiveVersion = 1
LEFT JOIN DCA_A1.DimECSF DP
ON DE.MemberSourceCode = DP.MemberSourceCode
AND DE.PurchaserOrgNumber = DP.PurchaserOrgNumber
AND DE.PurchaserOrgTypeCode = DP.PurchaserOrgTypeCode
AND DP.ContactType = 1
LEFT JOIN DCB_A1.DimMKBU DM
ON FE.MBUKey = DM.MarketingBusinessUnitKey
WHERE DE.IsActiveVersion = 2
--and DE.AccountID =2
--AND (DE.CustomerStatusCode = 'A'
-- OR DE.IsEmployerActive = 0)
----and CustomerStatusCode = 'A'
--AND (MBUStateCoverage <> '' and MBUStateCoverage <> 'UNK')
GROUP BY DE.AccountID,DE.SourceGroupNumber,
DE.MemberSourceCode,DE.GroupName,
ISNULL(DC.ContactValue,''), ISNULL(DN.ContactValue,''),
ISNULL(DN.ContactText2,''),ISNULL(DN.ContactText3,''),
ISNULL(DN.ContactText4,''),ISNULL(DP.ContactValue,'') ,SUBSTRING(MBUStateCoverage, 1, 2)
), EMK AS (
SELECT DISTINCT
1 AS RecordSource, --CMD
EA.EmployerKey,
EA.AccountID,
ISNULL(EA.SourceGroupNumber,'NA') AS SourceGroupNumber,
EA.SourceSubGroupNumber,
EA.PurchaserOrgNumber,
ISNULL(EA.GroupName,'NA') AS GroupName,
EA.MemberSourceCode
FROM
(SELECT FE.EmployerKey, DE.AccountID, DE.SourceGroupNumber, DE.SourceSubGroupNumber,DE.PurchaserOrgNumber,
DE.GroupName, DE.MemberSourceCode
FROM DCB_A1.FctESF FE
INNER JOIN DCB_A1.DimESF DE
ON FE.EmployerKey = DE.EmployerKey
LEFT JOIN DCB_A1.DimMKBU DM
ON FE.MBUKey = DM.MarketingBusinessUnitKey
where DE.IsActiveVersion = 1 AND DE.PurchaserOrgTerminationReasonCode <> '171'
--and (MBUStateCoverage <> '' and MBUStateCoverage <> 'UNK')
GROUP BY FE.EmployerKey, DE.AccountID, DE.SourceGroupNumber,DE.SourceSubGroupNumber,DE.PurchaserOrgNumber,
DE.GroupName, DE.MemberSourceCode)EA
)
Select Distinct
RecordSource
,EMK.EmployerKey
,EMK.AccountID
,EMK.SourceGroupNumber
,EMK.SourceSubGroupNumber
,EMK.PurchaserOrgNumber
,EMK.GroupName
,EMK.MemberSourceCode
,CASE WHEN ESA.EmailAddress = '' OR ESA.EmailAddress IS NULL THEN 'UNKNOWN#UNKNOWN.COM'
ELSE ESA.EmailAddress END AS EmailAddress
,CASE WHEN ESA.FirstName='' OR ESA.FirstName IS NULL THEN 'NA' ELSE ESA.FirstName END AS FirstName
,CASE WHEN ESA.MiddleName='' OR ESA.MiddleName IS NULL THEN 'NA' ELSE ESA.MiddleName END AS MiddleInitial
,CASE WHEN ESA.LastName='' OR ESA.LastName IS NULL THEN 'NA' ELSE ESA.LastName END AS LastName
,CASE WHEN ESA.ContactName='' OR ESA.ContactName IS NULL THEN 'NA' ELSE ESA.ContactName END AS ContactName
,ISNULL(ESA.PhoneNumber,'NA') As PhoneNumber
,'NA' AS MobilePhoneNumber
,'GROUP ADMINISTRATOR' AS ContactType
,ESA.StateCode
INTO DCB_A1.Temp_abc
FROM EMK
INNER JOIN ESA
ON EMK.AccountID = ESA.AccountID ;

Categories