I've been trying to create a function to load some files insert them into a temp table based on an existing table, then verifying that there are not duplicated rows on the files loaded and then inserting them into proper tables in the DB, tried using something like this:
let statement = " select * from ", vtable clipped, " where 1=0 into temp t_",vtable clipped
prepare pstatement from statement
execute pstatement
to no avail because the temp table seems to be created on a different session than the one im working in.
Any suggestions?
Thank you all beforehand
If you prepare and execute a statement as shown, it is created on the connection you're using at the time. If you don't mess with the connections (CONNECT, DISCONNECT, SET CONNECTION), then it should all be clean — if the statement worked at all. Are you checking errors (WHENEVER ERROR STOP, perhaps)? Or have you displayed statement to ensure the SQL is as expected (no untoward chopping of the string, for example — that could account for why the table appears to be missing).
Remember that a temporary table is private to the session. If you run a LOAD statement in the I4GL program, there should be no problem, but you can't use a separate loader program with a temporary table. In terms of the database, it would have to be a 'permanent' or 'regular' table, even if you remove it soon after creating it.
You could also prepare an explicit CREATE TEMP TABLE statement to create a table.
Also consider whether using an external table would help you with the loading. There are also violations tables that could be used to trap problematic rows while loading directly into the main table.
Related
I need to execute a script (Informix code) in a .sql file for migration purposes. The thing is, I want to load it from a function to be able to use the exception, therefore being able to do a rollback in case of an error.
So, this is the code (still experimenting):
DROP FUNCTION IF EXISTS "informix".SCRIPT_MIGRATION();
CREATE FUNCTION "informix".SCRIPT_MIGRATION()
RETURNS BOOLEAN as RESULT;
DEFINE lv_execute lvarchar(32739);
DEFINE li_errnum, li_eisam INT;
DEFINE lv_errtxt CHAR(200);
ON EXCEPTION SET li_errnum, li_eisam, lv_errtxt
ROLLBACK;
CALL regista_log('script_migration', get_session_user(), li_errnum, lv_errtxt);
RETURN 'f';
END EXCEPTION;
CALL set_isolation_level();
BEGIN;
LET lv_execute = 'LOAD FROM ''C:\Users\Admin\Desktop\ConstaWeb_Stuff\test.sql'' DELIMITER ''+'' INSERT INTO SCRIPT_MIGRATION_TEMP_TABLE;';
DROP TABLE IF EXISTS SCRIPT_MIGRATION_TEMP_TABLE;
CREATE TABLE SCRIPT_MIGRATION_TEMP_TABLE(
STRING_TO_EXECUTE LVARCHAR(31739)
);
EXECUTE IMMEDIATE lv_execute;
COMMIT;
RETURN 't';
END FUNCTION;
CALL SCRIPT_MIGRATION();
That's because we apparently can't execute the load command inside functions. So I'm trying to execute it. But I'm not getting it right, apparently...
The objective here is to execute the script (not a shell command script! it's an Informix script, like creates, loads, unloads, drops...) on a file. I'm open to other ways of doing this.
I'm relatively new to Informix so I'm sure there is still a lot I don't know about it.
As already noted, the LOAD command is not a command recognized by the Informix server. Client products emulate an SQL statement by recognizing the syntax and reading the file and executing appropriate SQL statements. Changing the way you (try to) execute it in a function executing in the server will not help.
Using a shell script instead may help.
If you're migrating an existing Informix database to a new location (machine, version of Informix), then using DB-export and DB-Import may be a good way to go.
The DB-Access command is the 'standard' way to execute scripts from a shell script. You'd need to ensure you set the DBACCNOIGN environment variable to 1. That will then stop if there's an error during the LOAD and rollback the transaction. There's also the DB-Load command, but it will be harder to rollback DDL statements since it does not handle those.
Alternatively, you might find my SQLCMD* program useful — though it too isn't perfect. However, unlike DB-Access, it allows you to control which statements can generate errors that are ignored and which are not (continue [on|off|push|pop]; before and after as appropriate).
With careful packaging, you can use it to create your migration, assuming the DB-Export and DB-Import won't do the job for you automatically.
* You may have to subscribe to the IIUG to get at this. The registration is not onerous, and neither is the email load.
In informatica mapping design, there must be a target table, but in my design, I only use informatica to call store procedures, and after they were called, all work has been done, so I don't need a target table to be inserted or updated.
I used a non-exist table as the target table, and one nonsense field as the input port(cause there must be at least one input port!), then unchecked or the option(insert, update,delete) in the session configuration, so that the informatica would not generated DML SQL statements, avoiding "no table" errors.
But then informatica treat the input row as reject row and try to write it into a bad file. And cause I unchecked the insert option, the session log showed that there was an error that it couldn't be insert into the bad file!
Strangely, this error never showed in the monitor, and all session run successfully! It only appeared in informatica's meta table.
Is there a better way to avoid this problem, although it has no effect to my result? Is there a possibility to use a non-exist table and do nothing to it (include reject the input rows)?
Use a filter transformation just before the target and put filter condition 'FALSE'
No rows will go to the target
I had run into this same issue when i wanted to just execute a stored procedure and nothing else.
I solved this by creating a dummy source object that had one port and a dummy target with one port of the same datatype. In the source qualifier I added a SQL statement select 1 from dual (since it's Oracle).
I then added a filter object that was set to false. Then I connected the single port from the source/qualifier through the filter and finally to the target.
When the mapping is run, the source qualifier will return 1 row of one value, this will pass through to the filter but nothing will come out of the filter because the filter is set to false. This mapping will always be successful and valid because all ports are connected a nothing makes it to the "dummy" target thus no bad file logs or failure, etc.
Let me know if you need any clarification and I can update this answer.
No, you always need a target for the mapping to be valid. But I would rather work with a flat file target instead of a database table, you'll have much less work to do.
If you're on Linux / Unix, you can even route the file to /dev/null (use folder:/dev/, file:null) so the file is not actually written to the filesystem.
And using one dummy port is the right way. As you have said, you need at least one port, even if you don't really use it.
As odd as this may sound (Unix systems): neither source, nor target need to exist.
Source (flat file): /dev/null, column DUMMY
Target (flat file): /dev/null, column DUMMY
And you don't need to use any databases for the session to succeed, nor use any filters. It runs.
We're trying to make a DTS package where it'll launch a stored procedure and capture the contents in a flat file. This will have to run every night, and the new file should overwrite the existing file.
This wouldn't normally be a problem, as we just plug in the query and it runs, but this time everything was complicated enough that we chose to approach it with a stored procedure employing temporary tables. How can I go about using this in a DTS package? I tried going the normal route with the Wizard and then plugging in EXEC BlahBlah.dbo... It did not care for that:
The Statement could not be parsed. Additional information: Invalid object name '#DestinyDistHS'. (Microsoft SQL Server Native Client 10.0)
Can anyone guide me in the right direction here?
Thanks.
Is it an option to simply populate a non-temp table in your SP, call it and select from the non temp table when exporting?
This is only an issue if you have multiple simultaneous calls to the stored procedure. In this case you can't save to a single table.
If you do have multiple simultaneous calls then you might be able to:
Create a temp table to hold results
Use INSERT INTO #TempTable EXEC YourProc
SELECT FROM #TempTable
You might need to do this in a more forgiving command line tool (like SQLCMD). It's not as fussy about metadata.
I am using ESQL/C code to provide backend support for a UI, connecting to an Informix database. I am creating temp table inside my code. But, I guess that if multiple users use this UI at the same time then temp table might already exist in the database which can create problem. So, can someone suggest if I can create temp table with PID as suffix inside my ESQL/C code
create temp table tabname_PID (name char(10));
In shell script I generally use tabname_$$.
You can create the table with the PID embedded in it, but it isn't necessary. Any temporary table is only visible in the session that creates it, so you can use the same table name in each session (separate but concurrently executing ESQL/C program) without any fear of conflict.
If, despite the reassurances that it is unnecessary, you still want to do it, then you'll have to PREPARE and EXECUTE (or DECLARE, OPEN, FETCH, CLOSE) the statements from a string:
snprintf(sql, sizeof(sql), "CREATE TEMP TABLE tabname_%d(name CHAR(10))", (int)getpid());
EXEC SQL PREPARE s FROM :sql;
EXEC SQL EXECUTE s;
or use EXECUTE IMMEDIATE (which is the obvious winner here):
EXEC SQL EXECUTE IMMEDIATE :sql;
You will also then have to prepare all the queries; one distinct advantage of using the fixed-name temporary table is that you don't have to prepare everything that references the temp table if you don't want to (though there are often advantages to using PREPARE etc).
You don't have to use $$ in shell scripts either, for the same reason — temporary tables are private to a session.
I have a strange problem
When I create Object Script (script to drop and create Stored Procedures, Views, Functions) from Sql Server 2008 it misses 3 Views don't know why?
I am performing Following steps to create object script
1) Open Sql Server 2008 Management Studio
2) Connect to server
3) Right click on selected database then click on Tasks -> Generate Script, then select database from list, click Next.
4) It gives options I am changing three options i.e. Include If Not Exists = true, Script Drop = true, Script Use Database = false and clicing Next button
4) Now selecting SP, Views and Functions and clicking Next,
5) clicking Select All for All the coming screens
6) Finally clicking Finish button.
Is there any limitation or special condition or convention that I am not following and causing Views not to include in Generate Script?
Please let me know if I am missing something , I have tried many ways.
I also found that this problem not only exists with Views but it also exists with Functions and Stored Procedures.
If we rename them it works fine , for example a Function earlier named dbo.SeperateElementsInt was working fine, but strangely, Generate Script ignored this function, later we renamed it to dbo.SeperateElementsInteger and it started generating script.
We cannot change the View names as it is used at many places.
Views which are giving problem are dbo.DivisionInfo and dbo.CustomerDivisonOfficeInfo
Stored Procedure which is giving problem is dbo.procsync_get_zVariable
The problem exists with SSMS 2005 too.
Thanks
We didn't understand each other on INFORMATION_SCHEMA-profiler issue. I was suggesting to turn profiler on, because SSMS does a SELECT on INFORMATION_SCHEMA with some where clauses. I suspect that the query itself cuts off your views. Once You have a query that SSMS executes to get the list of objects You should find why it doesn't see some views.
Here are the scripts that SSMS executes when You select all views and start scripting. Check if any of them doesn't return DivisionInfo view. (I've created DivisionInfo view in my database to reproduce your case). For quick check execute them one by one and read my comments after each query. Please note that You should actually catch queries on your environment with Profiler, because they may differ on your environment.
Before showing screen to select views, procedures, ... SSMS executes following script to get the list of views:
exec sp_executesql N'SELECT
''Server[#Name='' + quotename(CAST(
serverproperty(N''Servername'')
AS sysname),'''''''') + '']'' + ''/Database[#Name='' + quotename(db_name(),'''''''') + '']'' + ''/View[#Name='' + quotename(v.name,'''''''') + '' and #Schema='' + quotename(SCHEMA_NAME(v.schema_id),'''''''') + '']'' AS [Urn],
v.name AS [Name],
SCHEMA_NAME(v.schema_id) AS [Schema]
FROM
sys.all_views AS v
WHERE
(v.type = #_msparam_0)and(CAST(
case
when v.is_ms_shipped = 1 then 1
when (
select
major_id
from
sys.extended_properties
where
major_id = v.object_id and
minor_id = 0 and
class = 1 and
name = N''microsoft_database_tools_support'')
is not null then 1
else 0
end
AS bit)=0)
ORDER BY
[Schema] ASC,[Name] ASC',N'#_msparam_0 nvarchar(4000)',#_msparam_0=N'V'
Is your view listed? You can add condition WHERE v.name = 'DivisionInfo' to filter it. If there is no DivisionInfo listed check what part of this query eliminates it from result set.
Once You select objects to script and start scripting, SSMS creates temp table, store objects in it and executes scripts to find related objects.
Create temp table and insert DivisionInfo view in it:
CREATE TABLE #tempdep (objid int NOT NULL, objname sysname NOT NULL, objschema sysname NULL, objdb sysname NOT NULL, objtype smallint NOT NULL)
exec sp_executesql N'INSERT INTO #tempdep
SELECT
v.object_id AS [ID],
v.name AS [Name],
SCHEMA_NAME(v.schema_id) AS [Schema],
db_name(),
2
FROM
sys.all_views AS v
WHERE
(v.type = #_msparam_0)and(v.name=#_msparam_1 and SCHEMA_NAME(v.schema_id)=#_msparam_2)',N'#_msparam_0 nvarchar(4000),#_msparam_1 nvarchar(4000),#_msparam_2 nvarchar(4000)',#_msparam_0=N'V',#_msparam_1=N'DivisionInfo',#_msparam_2=N'dbo'
Did this query insert anything in #tempdep? If not, check why. Once again, You have to use Profiler to get queries from your environment instead of using queries I put here because they are from my environment.
When You start profiling, there should be many inserts like the one above. You need to find the one that relates to DivisionInfo. You can use Find option to find it because You will see many queries in Profiler because You have a lot of other views. To make profiler log smaller, script only views.
As You can see, idea is to start profiling and start scripting. Once scripting is finished, stop profiler and check scripts executed by SSMS. You should find why it doesn't see DivisionInfo. If there is no DivisionInfo in profiler log but You can check it for scripting in wizard, then take scripts for DivisionInfo and for one view that scripting works for and see the differences between them. Take a close look at differences between them in regards to scripts that SMSS uses to retrieve them.
for some reason SSMS discards this view
according to data he extracted with queries (catched from profiler)
I just ran into the exact issue. We were trying to script out the schema of one database (Call it Database_A) and many views wouldn't script out.
We'd decommissioned another database (Call it Database_B) and all the views that wouldn't script (in Database_A) pointed out to that database (Database_B) - which was accessed through a linked server, and was offline. Since all the connection strings were now pointing to the new server that Database_A was now on, I brought Database_A on the old server online in read_only for just long enough to script out the views, and it worked. Took the database offline again, and we had what we needed.
The script I threw together to find the linked server reference in the views was this:
use Database_B
go
select so.name, sc.text
from sysobjects so, syscomments sc
where so.id = sc.id
and sc.text like '%Database_A%'
That's what worked for me, I hope it works for you as well.
Take care,
Tom