We are just beginning to use COBOL stored procedures, but we are having a problem when using temporary tables. After we make the call to the COBOL program the connection times out. CMTSTAT is set to inactive. I'm thinking the problem is with the declare of the temp table with the on commit preserver rows, but don't know how to get around this. Any thoughts would be helpful
Actually found the answer to my question. We ended up doing a drop of the temporary table from the calling program and that worked.
Related
I'm usign the dbExpress components within the Embarcadero C++Builder XE environment.
I have a relatively large table with something between 20k and 100k records, which I display in a DBGrid.
I am using a DataSetProvider, which is connected to a SQLQuery and a ClientDataSet, which is connected to the DataSetProvider.
I also need to analyze the data and therefore I need to run through the whole table. For smaller tables I always used code, which is basically something like this:
Form1->ClientDataSet1->First();
while(!Form1->ClientDataSet1->Eof){
temp=Form1->ClientDataSet1->FieldByName("FailReason")->AsLargeInt;
//do something with temp
Form1->ClientDataSet1->Next();
}
Of course this works out, but it is very slow, when I need to run through the whole DBGrid. For some 50000 records in can take up to some minutes. My suspicion is that the most perform is lost since the DBGrid needs to be repainted as the actual Dataset increments its address.
Therefore I am looking for a method which allows me to either read the data without manipulating the actual ClientDataSet. Maybe a method which copies the data of a column into a variable, or another way to run through the datasets, which is more efficient. I am sure if I would have a copy in a variable the operation would take less than a few seconds...
I googled now for hours, but didn't find anything useful so far.
Best regards,
Bodo
if your cds is connected to some db-aware control(-s) (via TDataSource) then first of all consider using DisableControls()
another option would be to avoid utilizing FieldByName within the loop
I'm Erlang newbie. and I got a question about the ets tables.
I have two ets tables, and I need insert or delete values from both.
insert(V) ->
ets:insert(table_test,V),
ets:insert(table_cp,V).
delete(V)->
ets:delete(table_test,V),
ets:delete(table_cp,V).
how can I guarantee the operation was success or failed in both?
for example, the insert operation, if there is something wrong at ets:insert(table_cp,V), shall I delete the value from talbe_test?
same to delete, if ets:delete(table_cp,V) failed, shall I re-insert the value ?
please help.
What you are asking for is a transaction. ETS doesn't support transactions. Even if you don't insert the value in the other table if the first insert wasn't successful, you can't guarantee that you insert the second value if the first insert is successful because something may happen between those two writes, e.g. the process may die.
If you need transactions please consider mnesia which is built on top of ETS and provides support for transactions, even across distributed Erlang nodes.
It all depends how much you need to rely on the value being inserted to both or neither. If your application can survive (work correctly) with the value inserted only to one of those tables, or if it is able to correct the value if it's inserted incorrectly, then a programmatic handling of failures as you described may work fine. Otherwise ETS wouldn't be the right data structure.
I am using Delphi2010 and I'm trying to do an insert into multiple tables. I don't know the best way to do this. What I'm wondering is if there is a possible way to do one insert using one of Delphi's tools like the TQuery or TClientDataSet or would it be better to use code (we use Pascal language). An array maybe? I haven't been using Delphi that long but I have inserted and updated info into one table before, not multiple. Also, these tables use pretty much the same field names.
Any help would be greatly appreciated.
Thanks in advance!!
Call a stored procedure to update your tables simultaneously, with a transaction wrapper. Or re-design your database to eliminate duplicate/redundant data, so that you would never need to update several tables at once.
Note that this answer is perfectly valid, given the information provided in the question...
(Note: it's late, couldn't sleep, bored. This is what you get, given the quality of the information in the question!)
Another possible solution could be to make a updateable view on the database, and update the view from Delphi.
Making a updateable view just moves the work of updating 2 tables to the SQL instead of in Delphi.
This moves the business logic to the sql instead of in the Delphi. It propobly also generates less network trafic.
As Chris writes: use transactions, when 2 or more updates/inserts is dependent of each other.
Which data access componentes do you use ?
Which restrictions do you have ?
do you want to insert the same values into both tables ?
why not easy like:
for i = low(tables) to high(tables) do
begin
query.sql.text := 'insert into '+tables[i]+' (fields) values('+ ...)';
query.execsql;
end;
I am attemting to create a storedproc that reads like:
Select
ep.EmployeeID, GetEmployeeFirstName(ep.EmployeeID),
GetEmployeeLastName(ep.EmployeeID), ed.EmployeeDateOfBirth,
ed.EmployeeAddress, ed.EmployeeAddress2, ed.City, ed.State, ed.ZipCode
From
EmployeeProfile ep, EmployeeDetail ed
Where
ep.EmployeeID = ed.EmployeeID
This block of code will be a stored procedure.
My issue is that GetEmployeeFirstName is a stored proc that has to be passed an EmployeeID to get the employees first and last name.
How can I call a storedproc within a stored proc.
Thanks
Mike
These would probably be better suited as a function.
GetEmployeeFirstName(ep.EmployeeID), GetEmployeeLastName(ep.EmployeeID)
Better yet, just join the table that has the names.
I don't understand what these stored procedures do. Even if the first and last name are not in the EmployeeProfile table, and even if you have to do some manipulation of the strings before they are returned, a join would be a much better solution than a stored procedure or function. Especially when you take performance into account.
If you have the GetEmployeexName sprocs because you use them elsewhere, that's fine. Whatever they do, I would not consider it code duplication if they don't get called from your query.
You need to understand that for every row in your result set, two other procedures or functions get called. This is extremly costly and can render an application unacceptably slow, even for relatively small result sets of a few thousand employees. I know what I am talking about - I removed a lot of function calls from queries during a recent database tuning initiative.
In SQL Server, in order to call the GetEmployeeLastName within the Select statement list I would convert it to a database Function.
You can use EXEC or sp_executesql to execute a stored procedure from another stored procedure. (BTW, you have not specified your RDBMS).
Doesn't your table EmployeeDetail contain the employee's first and last name?
Select
ep.EmployeeID, ed.FirstName
ed.LastName, ed.EmployeeDateOfBirth,
ed.EmployeeAddress, ed.EmployeeAddress2,
ed.City, ed.State, ed.ZipCode
From
EmployeeProfile ep
inner join EmployeeDetail ed ON ep.EmployeeID = ed.EmployeeID
Let's say I have 'myStoredProcedure' that takes in an Id as a parameter, and returns a table of information.
Is it possible to write a SQL statement similar to this?
SELECT
MyColumn
FROM
Table-ify('myStoredProcedure ' + #MyId) AS [MyTable]
I get the feeling that it's not, but it would be very beneficial in a scenario I have with legacy code & linked server tables
Thanks!
You can use a table value function in this way.
Here is a few tricks...
No it is not - at least not in any official or documented way - unless you change your stored procedure to a TVF.
But however there are ways (read) hacks to do it. All of them basically involved a linked server and using OpenQuery - for example seehere. Do however note that it is quite fragile as you need to hardcode the name of the server - so it can be problematic if you have multiple sql server instances with different name.
Here is a pretty good summary of the ways of sharing data between stored procedures http://www.sommarskog.se/share_data.html.
Basically it depends what you want to do. The most common ways are creating the temporary table prior to calling the stored procedure and having it fill it, or having one permanent table that the stored procedure dumps the data into which also contains the process id.
Table Valued functions have been mentioned, but there are a number of restrictions when you create a function as opposed to a stored procedure, so they may or may not be right for you. The link provides a good guide to what is available.
SQL Server 2005 and SQL Server 2008 change the options a bit. SQL Server 2005+ make working with XML much easier. So XML can be passed as an output variable and pretty easily "shredded" into a table using the XML functions nodes and value. I believe SQL 2008 allows table variables to be passed into stored procedures (although read only). Since you cited SQL 2000 the 2005+ enhancements don't apply to you, but I mentioned them for completeness.
Most likely you'll go with a table valued function, or creating the temporary table prior to calling the stored procedure and then having it populate that.
While working on the project, I used the following to insert the results of xp_readerrorlog (afaik, returns a table) into a temporary table created ahead of time.
INSERT INTO [tempdb].[dbo].[ErrorLogsTMP]
EXEC master.dbo.xp_readerrorlog
From the temporary table, select the columns you want.