I'm porting a project from C# + SQL Server to Java + MySQL. I used ibatis 3 in the Java + MySQL project.
In the old projects, it used lots of stored procedures, which return more than 1 result sets.
I tried to find a solution using ibatis, and find this MyBatis multiple resultsets.
It seems James Woods has make it using comma-separated resultMap list.
I tried his method and call the method in Java like:
1: Object[] findCashItems(); 2: List[] findCashItems();
However, both of them failed.
I just wonder does the ibatis 3 really support stored procedures that return more than 1 result set?
If so, how could we call the method in Java?
Thanks a lot.
Last I checked, you need a return type like List or List<List<?>>.
Related
I tried to get value from query or to specify values, as soon as the parameter is multi value i can't see the data when i'm trying to make my subscription.
my request looks like :
select id from employee where canal in(#canal)
what should i do, i'm totally stuck,
when i did research i saw data driven subscription but i don't have access to it apparently, don't know if that help
I'll start by saying sorry this isn't a pleasant answer. You've run into a limitation with the built-in functionality. Thankfully there are workarounds.
The problem is that you can only pass 1 value into the data-driven subscription. So you have use a comma-separated list and get the query/report to parse out the values.
If you have or can create a Split function in your database, that is a good option. This would be a table-valued user defined function and there are some easy to find examples already. Also this function is generally good to have for other use cases anyway. With this your SQL would read:
where canal in Split(#canal)
SSRS works really well with SQL Server, but when you use an ODBC connection, the parameter support is limited. You can use the same multi-value parameter workaround that is required in those cases.
In the Dataset properties > parameters tab, use an expression like this to combine the values into a single comma-separated string surrounded by commas.
="," + Join(Parameters!canal.Value, ",") + ","
The SQL would look like this:
where # like '%,' + canal + ',%'
Basically, this searches row-by-row for values that are contained in the string.
In either case, the query in your data-driven subscription settings will need to return the comma-separated string. Then you can select that column in the report parameters value field. Hope this helps!
I have this piece of code in Oracle which I need to convert into SQL Server to get the same behavior. I have used the REPLACE function. It seems to be working but I just wanted to make sure.
REGEXP_REPLACE(
phonenumber,
'([[:digit:]]{3})([[:digit:]]{3})([[:digit:]]{4})',
'(\1)\2-\3'
) phonenumber
As Martin said in his answer, SQL Server does not have built-in RegEx functionality (and while it has not been suggested here, just to be clear: no, the [...] wildcard of LIKE and PATINDEX is not RegEx). If your data has little to no variation then yes, you can use some combination of T-SQL functions: REPLACE, SUBSTRING, LEFT, RIGHT, CHARINDEX, PATINDEX, FORMATMESSAGE, CONCAT, and maybe one or two others.
However, if the data / input has even a moderate level of complexity, then the built-in T-SQL functions will be at best be cumbersome, and at worst useless. In such cases it's possible to do actual RegEx via SQLCLR (as long as you aren't using Azure SQL Database Single DB or SQL Server 2017+ via AWS RDS), which is (restricted) .NET code running within SQL Server. You can either code your own / find examples here on S.O. or elsewhere, or try a pre-done library such as the one I created, SQL# (SQLsharp), the Free version of which contains several RegEx functions. Please note that SQLCLR, being .NET, is not a POSIX-based RegEx, and hence does not use POSIX character classes (meaning: you will need to use \d for "digits" instead of [:digit:]).
The level of complexity needed in this particular situation is unclear as the example code in the question implies that the data is simple and uniform (i.e. 1112223333) but the example data shown in a comment on the question appears to indicate that there might be dashes and/or spaces in the data (i.e. xxx- xxx xxxx).
If the data truly is uniform, then stick with the pure T-SQL solution provided by #MartinSmith. But, if the data is of sufficient complexity, then please consider the RegEx example below, using a SQLCLR function found in the Free version of my SQL# library (as mentioned earlier), that easily handles the 3 variations of input data and more:
SELECT SQL#.RegEx_Replace4k(tmp.phone,
N'\(?(\d{3})\)?[ .-]*(\d{3})[ .-]*(\d{4})', N'($1)$2-$3',
-1, -- count (-1 == unlimited)
1, -- start at
N'') -- RegEx options
FROM (VALUES (N'8885551212'),
(N'123- 456 7890'),
(N'(777) 555- 4653')
) tmp([phone]);
returns:
(888)555-1212
(123)456-7890
(777)555-4653
The RegEx pattern allows for:
0 or 1 (
3 decimal digits
0 or 1 )
0 or more of , ., or -
3 decimal digits
0 or more of , ., or -
4 decimal digits
NOTE
It was mentioned that the newer Language Extensions might be a better choice than SQLCLR. Language Extensions allow calling R / Python / Java code, hosted outside of SQL Server, via the sp_execute_external_script stored procedure. As the Tutorial: Search for a string using regular expressions (regex) in Java page shows, external scripts are actually not a good choice for many / most uses of RegEx in SQL Server. The main problems are:
Unlike with SQLCLR, the only interface for external scripts is a stored procedure. This means that you can't use any of that functionality inline in a query (SELECT, WHERE, etc).
With external scripts, you pass in the query, work on the results in the external language, and pass back a static result set. This means that compiled code now has to be more specialized (i.e. tightly-coupled) to the particular usage. Changing how the query uses RegEx and/or what columns are returned now requires editing, compiling, testing, and deploying the R / Python / Java code in addition to (and coordinated with!) the T-SQL changes.
I'm sure external scripts are absolutely wonderful, and a better choice than SQLCLR, in certain scenarios. But they certainly do not lend themselves well to the highly varied, and often ad hoc, nature of how RegEx is used (like many / most other functions).
SQL Server does not have native regex support. You would need to use CLR (or as #Lukasz Szozda points out in the comments one of the newer Language Extensions) .
If I have understood the regex correctly though it matches strings of 10 digits and assigns the first 3 to group 1, second 3 to group 2, and last 4 to group 3 and then uses the back references in the expression (\1)\2-\3
You can use built in string functions to do this as below
SELECT CASE
WHEN phonenumber LIKE REPLICATE('[0-9]', 10)
THEN FORMATMESSAGE('(%s)%s-%s',
LEFT(phonenumber, 3),
SUBSTRING(phonenumber, 4, 3),
RIGHT(phonenumber, 4))
ELSE phonenumber
END
You can write SQL function using CLR, that will wrap standard dotnet regex. I have wrote this and you can use it there. It will look this:
DECLARE #SourceText NVARCHAR(MAX) = N'My first line <br /> My second line';
DECLARE #RegexPattern NVARCHAR(MAX) = N'([<]br\s*/[>])';
DECLARE #Replacement NVARCHAR(MAX) = N''
DECLARE #IsCaseSensitive BIT = 0;
SELECT regex.Replace(#SourceText, #RegexPattern, #Replacement, #IsCaseSensitive);
I'm learning MSBI tools and came across a requirement in SSRS wherein we need to constrain report parameter 2 with parameter 1.
i.e. if I have parameters setup on [AdventureWorks2008R2].[HumanResources].[Department] table and if I select "Group Name" (Parameter 1) as "Manufacturing" then the "Name" (Parameter 2) drop down should populate only relevant values("Production" and "Production Control") specific to selected parameter 1 value ("Manufacturing")
I have been exposed to OBIEE tool and know that under this tool we have a "constrain" option under Prompts to achieve the same.
I could come up with the following solution under SSRS:
Created two datasets for each of the parameters with below queries.
Parameter 1 (GroupName)
SELECT DISTINCT GroupName
FROM HumanResources.Department
Parameter 2 (DeptName)
SELECT Name
FROM HumanResources.Department
WHERE (GroupName = #GroupName)
This worked. However if there are 5 such parameters which are to be constrained then with this solution I would have to create 5 such datasets and accordingly build the WHERE clause for each parameter.
Is there a better solution to achieve the same (there should be..)
I'm new to SSRS and therefore would appreciate any pointers here.
Thanks!
What you are talking about is called "Cascading Parameters" and they are implemented exactly as you did. You can read about them here:
Adding Cascading Parameters (SSRS)
So if you need to implement 5 of such parameters you have to write 5 queries for 5 datasets each one containing WHERE referencing parameter defined in previous dataset
I am looking through some old code and found a piece that i cant' seem to understand the point of....As far as i can tell, it's just a simple insert. but why did they do it this way? would it be okay to rewrite into an insert, or could i potentially break something?
please see below:
Set TextRS = Server.CreateObject("ADODB.RecordSet")
Set TextRS.ActiveConnection = Conn
TextRS.Source = "SELECT IDX,TIMESTAMP,CURRENTFLAG,TEXT FROM " & TextTable & " WHERE 1=2 FOR UPDATE"
TextRS.CursorLocation = 2
TextRS.CursorType = 3
TextRS.Open ,,,3
TextRS.AddNew
TextRS(0).Value = IDX
TextRS(1).Value = Timestamp
TextRS(2).Value = "Y"
TextRS(3).AppendChunk TextPiece
TextRS.Update
TextRS.Close
This part of the source confused me a bit.... where 1 = 2???
Apparently it had a purpose to ensure no match.
Anyway this style of programming is fairly old using ADO technology and people coming from DAO to ADO would often open up a cursor to iterate over the database this way... it does not follow modern best practices on how to do things, you can and should replace it with an insert statement!
It is possible that it was written pre jet4.0/access 2000 in which case it was an attempt to simulate a parameterized stored procedure. Though if the system is at all more modern than that I would strongly recommend using a stored procedure as it has multiple benefits. Cached Execution Plans, Parameters to reduce the chances of SQL injection
I actually used to write code very much like that 12 years ago or so :p Mostly because I just didn't know better, regardless of the tech in use.
Ah, good old classic ASP ;)
The 1 = 2 forces the sql to never return a match. It's basically a way of building up the command (?) so that you can then "conveniently" change the values and then an update will store it.
I've seen it done before, but never did it that way myself. As others have said, a simple paremetised INSERT statement will be better, IMO.
I would rewrite this using parameterized ADO query. The method being used has an unnecessary SELECT, which makes the INSERT slower.
That code seems a bit obscure, but all they are doing is creating an empty instance of a recordset row so the values can be set and the recordset resaved. This is bound to be much slower than doing a straight INSERT.
I would utilize an insert statement. The above mentioned code seems a little bit "lazy"... as in "let ADO do the work for me". However, there is nothing really wrong with it. The where 1=2 part was there to return an "empty table"... um... I mean recordset.
I'm new to SSRS. We'll have two slightly different chunks of XML in a single row of an SQL Server database table. In an SSRS report we'll want to show only the differences between the XML chunks. I don't know how to do this, but I suspect the XML Type in SQLServer 2005 might be useful, or XSLT transformations in SSRS. Could anyone point me in the right direction?
I didn't underetand your question as well, But if you mean that, You have two XML (string) and in your Report you want to show just the different partof these two strings.
If I were you, I wrote a class in .NET (c#) which 'take two xml' and process the different with .NET abilities, then I return the different in an Array like
note that the following code is a pseudu code not a real one.
public string[] ComapreXML(XMLDocument first, XMLDocument second)
{
string[] result = null;
if(first.element.content != second.element.content)
result.add(first.element.getData());
return result;
}
the I'd compile this class and add this class to SSRS (I wrote an article about How to extend SSRS Functionalities here)
And finally inthe report I use this code to get result.
Let me know was it usefull or not.
I am not sure whether there is something readily available to identify the differences in two XML documents. However, I once wrote a function that can compare two XML documents and say whether they have the same content or not.
You can find the code here. May be you can take the code, modify it and return the differences between the two XML documents - in case no other option is left.