I have in SAS Enterprise Guide 6.1 a libname assigned to a database through ODBC.
If in Server List panel I select table attached to the libname, and open it with right mouse menu, I get the resulting table which I can browse.
Is is possible to see somehow which SQL query the opening of the table sends to the ODBC interface?
Addition 1:
I would like to compare the performance when running a proc sql query:
proc sql;
select *
from temp.cases (obs=100);
quit;
And when opening the table with right mouse menu and with Tools > Options > Data > Performance > Maximum number of rows ... settings set to the value of 100.
In order to be able to explain the differences in performance I would need to know which query the opening of the table with right-mouse menu uses. Does is read the full table, and then show 100 lines, or read just 100 lines and then show those 100 lines. There could be a huge difference in performance between these two ways of showing data.
Or, is the only way to find out the query used in opening of the data to look at the log of the server which processed the ODBC query?
Addition 2:
The problem I had was caused by the string length of some fields, which became the maximum 32767. With 48 string fields that was 48 * 32767 = 1.5 M per one row! Apparently no strings had an "end-of-record" mark, which caused the huge data traffic between SAS Server and SAS Client.
After the data was reformatted to have only the string length with maximum of 255, one row took only 48 * 255 = 12 k, which make a tremendous difference in the speed, when viewing the data by "Opening" the table in SAS Guide viewer! Similar performance loss was not seen when outputting the same data into "SAS Report".
I'm not sure that it is possible to see a SQL version of what is happening. Since it is SAS, it is probably using a data step or equivalent to populate the table browsing (like using obs= option on a data step set statement).
However, if you are simply looking to find a proc sql equivalent. The outobs option may work for you.
proc sql outobs=10;
create table temp2 as select * from temp;
run;
Related
I am having a an issue with SQL Command and CASE. I am pretty new to Crystal Reports/SQL and I have a basic code that I am playing around with to learn. I want to clean out a field -- that has imported from SQL Server. I just want to do something simple like this:
SELECT "I"."I_TYPE", "Alleg” =
CASE
WHEN "ALLEGs"."ALLEG” LIKE ‘*im*’ THEN ‘Improper’
ELSE ‘UNKNOWN’
END
I get an error that says Database Connector Error:
'42000:[MS][SQL..Incorrect syntax near ' . ' . Databse vender code 102.
Can you even use CASE as an IF THEN statement in the SQL Command. I am aware of SQL expressions, but I am trying to pull data to sql command to prevent performance decrease.
I am not sure about crystal report but your query formation don't look correct. It should be
SELECT I.I_TYPE,
CASE WHEN ALLEGs.ALLEG LIKE '%im%' THEN 'Improper' ELSE 'UNKNOWN' END AS 'Alleg'
Rahul, is correct for direct SQL commands to the server.
However sometimes when running Crystal Reports we use VBA within the report to do some data tuning rather than modifying the raw SQL on the fly.
This leaves the raw SQL a known result (verifiable on the SQL Server) and then modify the output in Crystal to fit the end users filtering requirements.
This is not efficient with large result sets but when the results are smaller (under 50k records) we usually have our team go with simple (post filtering) to reduce design and testing time.
This technique works very well with dynamic filters on the option section.
example: [Record Selection]
if {?Select Sales Person} <> "ENT" then
{R0033___P2A.ProjectionSP} = {?Select Sales Person} and {R0033___P2A.FM} >= 0
else
{R0033___P2A.ProjectionSP} > "" and {R0033___P2A.FM} >= 0
Where {?Select Sales Person} is a user selection filter and {R0033___P2A} is a predefined report view or stored procedure.
My project is in Visual Foxpro and I use MS SQL server 2008. When I fire sql queries in batch, some of the queries don't execute. However, no error is thrown. I haven't used BEGIN TRAN and ROLLBACK yet. What should be done ??
that all depends... You don't have any sample of your queries posted to give us an indication of possible failure. However, one thing I've had good response with from VFP to SQL is to build into a string (I prefer using TEXT/ENDTEXT for readabilty), then send that entire value to SQL. If there are any "parameter" based values that are from VFP locally, you can use "?" to indicate it will come from a variable to SQL. Then you can batch all in a single vs multiple individual queries...
vfpField = 28
vfpString = 'Smith'
text to lcSqlCmd noshow
select
YT.blah,
YT.blah2
into
#tempSqlResult
from
yourTable YT
where
YT.SomeKey = ?vfpField
select
ost.Xblah,
t.blah,
t.blah2
from
OtherSQLTable ost
join #tempSqlResult t
on ost.Xblah = t.blahKey;
drop table #tempSqlResult;
endtext
nHandle = sqlconnect( "your connection string" )
nAns = sqlexec( nHandle, lcSqlCmd, "LocalVFPCursorName" )
No I don't have error trapping in here, just to show principle and readability. I know the sample query could have easily been done via a join, but if you are working with some pre-aggregations and want to put them into temp work areas like Localized VFP cursors from a query to be used as your next step, this would work via #tempSqlResult as "#" indicates temporary table on SQL for whatever the current connection handle is.
If you want to return MULTIPLE RESULT SETs from a single SQL call, you can do that too, just add another query that doesn't have an "into #tmpSQLblah" context. Then, all instances of those result cursors will be brought back down to VFP based on the "LocalVFPCursorName" prefix. If you are returning 3 result sets, then VFP will have 3 cursors open called
LocalVFPCursorName
LocalVFPCursorName1
LocalVFPCursorName2
and will be based on the sequence of the queries in the SqlExec() call. But if you can provide more on what you ARE trying to do and their samples, we can offer more specific help too.
Typically, it is possible to know how many lines a query returns by using COUNT(*).
In the same manner, is there any way know how many megabytes for example the output of a given query is ?
Something like
SELECT MEMORYUSE(*) FROM bla bla bla
EDIT : I like the *exec sp_spaceused ... * approach, as it can be scripted!
For completeness, there are a couple of options to give you more information about the executing / executed query that you can view / set using SSMS as well. As shown below, the rowcount for the query is shown in the bottom right of SSMS by default. Also, I've highlighted the advanced query options, which you can set globally as shown here. Of course, you can also turn any of these options on for the particular statement or batch by including them in the query, i.e. 'set showplan_test on', etc..
Also you can turn on 'show client statistics' in SSMS as shown below (with sample output).
If you're using SQL Server, turn on Client Statistics and you 'll find "Bytes sent from client" and "Bytes received from server"
Here is related question
SQL Finding the size of query result
I think this will be useful:
SQL Server Query Size of Results Set
I don't think there is anyway without creating a temp table for the results and checking the size.
I'm getting the following error: AeSymResolveStatement [775] ... Meta-SQL error at or near position 34338 in statement (108,512). The SQL statement itself is over 40,000 chars long, hence the question.
The DB is oracle. Running on Tools 8.49.24.
I know that there is a limit on the size of the SQL used in an Application Engine (SQL Step). I had once recieved a similar error while trying to use an exceptionally long SQL in an Application Engine.
I wouldn't be surprised if that same limit applies to SQL Objects.
To fix the problem, I was able to split the SQL into 2 (was an update statement). Hopefully that's possible in your case as well.
There is no such limit.
You can confirm this yourself by creating an SQL like:
select 'x' from PS_INSTALLATION where
1 = 1 and
1 = 1 and
1 = 1 and
1 = 1 and
/* ... copy paste '1 = 1 and' 90000 times or so times more */
1 = 1
Although it makes pside quite slow, It saves and validates just fine.
There are limits within PeopleCode, mostly due to the limits on string length, however I have never found a limit on stored SQL statements.
Personally I'd look at breaking the statement into pieces in some way.
You could:
Using the inbuilt looping mechanism of App Engines
Use a mixture of SQL and PeopleCode
Use a temporary table and perform intermediate SQLs, storing in the temp table
Apart from giving your database a heart seizure, not the mention the DBA when he sees the statement in the SQL monitor. You are saving yourself a world of pain if you ever have to look at the statement again.
I think the SQLs in App Engines are stored as longs, so it would be 4GB under Oracle, something similarly huge under DB2.
In PL/SQL Developer v7.1.x, is there way way to ignore large data types in queries or the "Query Data" feature. For example: If you right click on table FOO, and select "Query Data" this will execute a SELECT * FROM FOO. If that table contains BLOB data the query will take a while to complete and temporarily lock up the application. This is especially problematic when querying remote databases (for obvious reasons).
I would like a way to tell PL/SQL Developer not to retrieve large data by default. I know there is a way to limit the ResultSet size but this doesn't do what I am looking for.
I could just select each column I wanted ignoring certain ones but then I couldn't use the "Query Data" feature.
Thanks.
No, the Query Data feature does one thing and one thing only - queries all the data.
What you might find useful is that you can drag the name of a table or view from the Browser into a SQL Window, choose "Select" from the menu that pops up, and it will generate a SELECT statement on the table with all the column names included - but does not execute the query straight away. You can then edit it however you like (e.g. comment out the LOB columns) before you run it.
I know that Toad has something like that built in, but I'm not aware of a PL/SQL Developer option that disables BLOBS.
The option you are left with, for now, is to simply select all the columns individually and truncate the blob.
ie:
select foo, bar, trunc(baz,100) from foo where ...
Create a View that doesn't contain the blob column or whatever columns you don't routinely want to look at.