Is it possible to script schema of the entire database (SQL Server or Postgres) using datagrip?
I know I can get DDL for table and view and source for each stored procedure / function on it's own.
Can I get one script for all objects in database at once?
Alternatively, is there a way to search through code of all routines at once, say I need to find which ones are using #table temp table?
From 2018.2 there is a feature called SQL generator. It will generate the whole DDL for the database/schema with several available options.
The result is:
BUT:
If you want just to understand where the table is used, please use the dedicated functionality which is called Find Usages (Alt+F7 or context menu on a table name)
I was looking for this today and just found it. If you right click the schema you want to copy and choose "Copy DDL" this will copy the create script to the clipboard.
To answer your second part of the question: quick and easy way to search for #table in all of your procedures you can do the following query
SELECT *
FROM information_schema.routines
WHERE routine_definition LIKE '%#table%'
For now only dumping tables works. In 2016.3 EAP which will be available in the end of August there will be an integration with mysqldump and pg_dump.
Background
Hi,
I work with a Unix-based application that uses an Intersystems Caché database. Since I'm not that familiar with Caché, it wasn't until recently that I found out I could type...
$ cache
...to enter the database. From here, I found out I could access a number of things like the %FREECNT report, the ^DATABASE routine (to view/modify the size and other properties of the database), and $SYSTEM.SQL.Shell().
Since I found the $SYSTEM.SQL.Shell(), I've found a number of things I can use it for to obtain info about the database, specifically running processes using the %SYS.ProcessQuery table.
I'm able to run queries successfully - for example:
USER>ZN "%SYS"
%SYS>D $SYSTEM.SQL.Shell()
SQL Command Line Shell #Comment - Sql Shell Intro text
--------------------------------
Enter q to quit, ? for help.
%SYS>Select PID As Process_ID, State As Process_Status From %SYS.ProcessQuery
The above query will return results in this format:
Process_ID Process_State
--------------------------------
528352 READ
2943582 HANG
707023 RUN
3 Rows(s) Affected
--------------------------------
Question
Considering the background identified above, I'm looking for a way to return just the results without the "SQL Command Line Shell" intro text, the column names, or the row count footer. When I write a .ksh script in Unix to connect to Caché and run a query, like above, I return the results, along with the following text that I don't want included:
SQL Command Line Shell
--------------------------------
Enter q to quit, ? for help.
Process_ID Process_State
--------------------------------
3 Rows(s) Affected
--------------------------------
Additional Info
I realize I could use Unix commands to filter out some of the text using awk and sed, but I'm looking for something a little easier/cleaner way that might be built-in. Maybe something that has a silent or no_column_names flag, like the example in this LINK.
My end game is to have a script run that will obtain info from a query, then use that info to make changes to the database when certain thresholds are met. Ultimately, I want to schedule the script to run at regular intervals, so I need all the processing to occur on the server instead of creating a separate Client app that binds to the database.
You want to create a Cache Routine for this. You can do this in Cache Studio.
http://docs.intersystems.com/ens20131/csp/docbook/DocBook.UI.Page.cls?KEY=GSTD_Routines
In the Routine, you want to use either Embedded SQL or Dynamic SQL to run the query, and iterate through the results, and print them using WRITE. I would recommend Dynamic SQL, as it will be more flexible in the future.
Introduction to SQL:
http://docs.intersystems.com/ens20131/csp/docbook/DocBook.UI.Page.cls?KEY=GSQL_intro#GSQL_intro_embeddedsql
Dynamic SQL Information:
http://docs.intersystems.com/ens20131/csp/documatic/%CSP.Documatic.cls?APP=1&LIBRARY=%SYS&CLASSNAME=%SQL.Statement
Embedded SQL Information:
http://docs.intersystems.com/ens20131/csp/docbook/DocBook.UI.Page.cls?KEY=GSQL_esql
You can create duplicate class of %SQL.Shell in your own namespace and you can edit it..If you want as Rountine means you can call this method ...%Go() from your routine.
how to specify no of records to delete in Tibco JDBC Update activity in batch update mode.
Actually I need to delete 25 million of records from the database so I wrote Tibco code to do the same and it is taking lot of time .. So I am planning to use Batch mode in Delete query so I don't know how to specify no of records in JDBC Update activity.
Help me if any one has any idea.. thanks
From the docs for the Batch Update checkbox:
This field is only meaningful if there are prepared parameters in the
SQL statement (see Prepared Parameters).
In which case the input will be an array of records. It will execute the statement once for each record.
To avoid running out of memory, you will still need to iterate over the 25mil, but you can iterate in groups of 1000 or 10000.
If this is not something you would do often (deleting 25M rows, sounds pretty one-off), an alternative is to use BW to create a file containing the delete statements and then giving the file to a DBA to execute.
please use subset feature of jdbc palette!! Let me know if you face any issues?
I would suggest two points:
If this is an one time activity then it is not adviced to use Tibco BW code for that. SQL script should be the better alternative.
When you say 25 million records- what criteria is this based on. It can be achieved through subset iteration .But there should be proper load testing in the Pre - Prod environment to check that the process is not causing any memory/DB issue.
You can also try using SQL procedure and invoking the same through BW.
I have some reports written in Crystal 2008 using business views. These reports have a date parameter set up and I have a selection on the date defined in the select expert. However, when I run the report it appears to retrieve all the data from the database and only then filter out based on the date. As you can imagine this slows down the report quite a bit. I also clicked on Database-Show SQL Query and confirmed that the date parameter did not appear in the SQL Query. This behavior seems very strange to me. This did not use to happen to me when I used Crystal 8.5 with dictionaries. Is this a limitation using business views?
I did some searching and found that I can create a report using a database command. This helped improve performance on one of my reports but when I tried to do something similar on a different report, even though I was using the database command, it still did not appear in the appear to be doing the selection on the database before retrieving the data and the report took forever to run. I also didn't see the selection in the SQL Query.
Do I need to add the parameter to the database command? Will I be able to prompt the user to enter the value when they run the report?
I hope there is a way to do this properly using business views because otherwise I'll have to rewrite all my reports to use another method.
Any ideas or advice are welcome. Thank you very much!
I had a similar problem. I used the command, but my report was still taking longer than i had hoped to run. so i added a where statement into the command to start checking dates starting from 2009. that sped up my report a little.
you may want to consider creating a stored procedure if you think you are pushing CR to the limit. that may also help sped up the report.
I figured out what the problem is. My business view had fields in it that were formulas. If you try to use selection criteria using a formula, it does not add the criteria to the WHERE clause in the SQL Query. Luckily, I was able to find other fields besides the formula in the business view to do the selection.
I have an SSRS report that calls out to a stored procedure. If I run the stored procedure directly from a query window, it will return in under 2 seconds. However, the same query run from an 2005 SSRS report takes up to 5 minutes to complete. This is not just happening on the first run, it happens every time. Additionally, I don't see this same problem in other environments.
Any ideas on why the SSRS report would run so slow in this particular environment?
Thanks for the suggestions provided here. We have found a solution and it did turn out to be related to the parameters. SQL Server was producing a convoluted execution plan when executed from the SSRS report due to 'parameter sniffing'. The workaround was to declare variables inside of the stored procedure and assign the incoming parameters to the variables. Then the query used the variables rather than the parameters. This caused the query to perform consistently whether called from SQL Server Manager or through the SSRS report.
I will add that I had the same problem with a non-stored procedure query - just a plain select statement. To fix it, I declared a variable within the dataset SQL statement and set it equal to the SSRS parameter.
What an annoying workaround! Still, thank you all for getting me close to the answer!
Add this to the end of your proc: option(recompile)
This will make the report run almost as fast as the stored procedure
I had the same problem, here is my description of the problem
"I created a store procedure which would generate 2200 Rows and would get executed in almost 2 seconds however after calling the store procedure from SSRS 2008 and run the report it actually never ran and ultimately I have to kill the BIDS (Business Intelligence development Studio) from task manager".
What I Tried: I tried running the SP from reportuser Login but SP was running normal for that user as well, I checked Profiler but nothing worked out.
Solution:
Actually the problem is that even though SP is generating the result but SSRS engine is taking time to read these many rows and render it back.
So I added WITH RECOMPILE option in SP and ran the report .. this is when miracle happened and my problem got resolve.
I had the same scenario occuring..Very basic report, the SP (which only takes in 1 param) was taking 5 seconds to bring back 10K records, yet the report would take 6 minutes to run. According to profiler and the RS ExecutionLogStorage table, the report was spending all it's time on the query. Brian S.'s comment led me to the solution..I simply added WITH RECOMPILE before the AS statement in the SP, and now the report time pretty much matches the SP execution time.
I simply deselected 'Repeat header columns on each page' within the Tablix Properties.
If your stored procedure uses linked servers or openquery, they may run quickly by themselves but take a long time to render in SSRS. Some general suggestions:
Retrieve the data directly from the server where the data is stored by using a different data source instead of using the linked server to retrieve the data.
Load the data from the remote server to a local table prior to executing the report, keeping the report query simple.
Use a table variable to first retrieve the data from the remote server and then join with your local tables instead of directly returning a join with a linked server.
I see that the question has been answered, I'm just adding this in case someone has this same issue.
I had the report html output trouble on report retrieving 32000 lines. The query ran fast but the output into web browser was very slow. In my case I had to activate “Interactive Paging” to allow user to see first page and be able to generate Excel file. The pros of this solution is that first page appears fast and user can generate export to Excel or PDF, the cons is that user can scroll only current page. If user wants to see more content he\she must use navigation buttons above the grid. In my case user accepted this behavior because the export to Excel was more important.
To activate “Interactive Paging” you must click on the free area in the report pane and change property “InteractiveSize”\ “Height” on the report level in Properties pane. Set this property to different from 0. I set to 8.5 inches in my case. Also ensure that you unchecked “Keep together on one page if possible” property on the Tablix level (right click on the Tablix, then “Tablix Properties”, then “General”\ “Page Break Options”).
I came across a similar issue of my stored procedure executing quickly from Management Studio but executing very slow from SSRS. After a long struggle I solved this issue by deleting the stored procedure physically and recreating it. I am not sure of the logic behind it, but I assume it is because of the change in table structure used in the stored procedure.
I Faced the same issue. For me it was just to unckeck the option :
Tablix Properties=> Page Break Option => Keep together on one page if possible
Of SSRS Report. It was trying to put all records on the same page instead of creating many pages.
Aside from the parameter-sniffing issue, I've found that SSRS is generally slower at client side processing than (in my case) Crystal reports. The SSRS engine just doesn't seem as capable when it has a lot of rows to locally filter or aggregate. Granted, these are result set design problems which can frequently be addressed (though not always if the details are required for drilldown) but the more um...mature...reporting engine is more forgiving.
In my case, I just had to disconnect and connect the SSMS. I profiled the query and the duration of execution was showing 1 minute even though the query itself runs under 2 seconds. Restarted the connection and ran again, this time the duration showed the correct execution time.
I was able to solve this by removing the [&TotalPages] builtin field from the bottom. The time when down from minutes to less than a second.
Something odd that I could not determined was having impact on the calculation of total pages.
I was using SSRS 2012.
Couple of things you can do, without executing the actual report just run the sproc from within the data tab of reporting services. Does it still take time?
Another option is to use SQL Profiler and determine what is coming in and out of the database system.
Another thing you can do to test it, so to recreate a simple report without any parameters. Run the report and see if it makes a difference. It could be that your RS report is corrupted or badly formed that may cause the rendering to be really slow.
Had the same problem, and fixed it by giving the shared dataset a default parameter and updating that dataset in the reporting server.
DO you use "group by" in the SSRS table?
I had a report with 3 grouped by fields and I noticed that the report runed very slowly despite having a light query, to the point where I can't even dial values in the search field.
Than I removed the groupings and now the report goes up in seconds and everything works in an instant.
In our case, no code was required.
Note from our Help Desk: "Clearing out your Internet Setting will fix this problem."
Maybe that means "clear cache."