database-connection
| connect to |
MySql |
database on |
localhost |
with username |
dbgreenpepper |
and password |
dbgreenpepper |
and database |
dbgreenpepper |
Stored Procedures
The Execute interpreter can be used similar to the Rule For interpreter to specify behaviour of stored procedures and functions.
| execute |
procedure |
|
CalcLength |
| name |
str length? |
| mika |
4 |
| paradajz |
8 |
| saeiluhrweurhfi7fhi7rhgf |
24 |
Multiple parameters and human-readable names
You can specify multiple parameters, with blanks in names and different letter casing
| execute |
procedure |
|
ConcatenateStrings |
| first string |
second string |
concatenated? |
| Hello |
World |
Hello World |
| Ford |
Prefect |
Ford Prefect |
Special case with no parameters
If there are no parameters, you don't need to specify the second header row
| execute |
procedure |
|
MakeUser |
| set of |
query |
|
select * from users |
| name |
username |
| user1 |
fromproc |
Order of parameters
table parameter order does not have to match database parameter order
| execute |
procedure |
|
ConcatenateStrings |
| second string |
concatenated? |
first string |
| World |
Hello World |
Hello |
| Prefect |
Ford Prefect |
Ford |
IN/OUT params
In/Out parameters of stored procedures should be specified twice. Once for the input and once for the expected output.
| execute |
procedure |
|
Multiply |
| factor |
val |
val? |
| 5 |
10 |
50 |
Stored functions are treated like procs - just put ? in the result column header
| execute |
procedure |
|
ConcatenateF |
| first string |
second string |
? |
| Hello |
World |
Hello World |
| Ford |
Prefect |
Ford Prefect |
? does not have to appear on the end (although it is a good practice to put it there)
| execute |
procedure |
|
ConcatenateF |
| second string |
? |
first string |
| World |
Hello World |
Hello |
| Prefect |
Ford Prefect |
Ford |
