u/Judith_677
-
0points
-
0points
Identify one pair of records per group that meet the criteria - student grades (self.databasedevelopment)
-
0points
Why does my “never-expiring” Discord invite link still expire? (self.discordapp) [:Discussion: Discussion]
-
1points
Search for Top N Values And Last N Values (self.esProc_Desktop)
-
2points
Search for The Nth Value And The Nth Value from Last (self.esProc_Desktop)
-
1points
Search for A Specified String across The Whole Table (self.esProc_Desktop)
-
1points
Split Words as Individual Characters (self.esProc_Desktop)
-
1points
Get The Same Rows from A Table (self.esProc_Desktop)
Judith_677
Judith_677
such a tiny cuite pie! Maybe a small cat-sized escalator would be helpful.
Judith_677
Thank you so much. I've found the seetings of use numbers and regenerated a new link. Hope this one do not expire.
Judith_677
When migrating SQL statements from one database to a different type of database, fully automated migration of SQL should not be possible due to differences in database functionality. However, for the reporting business, although the SQL used is relatively complex, they are mostly computational operations such as SELECT …. These SQL statements usually do not involve database functional issues such as transactions, and the differences mainly focus on the syntax of functions, which is relatively easy to solve. However, there are still inconsistencies in functions or calculation functions (such as KEEP in Oracle not corresponding in many other databases, and the support for window functions in different databases is also different), which prevent complete migration.
It is easy to think of using ORM framework to implement SQL conversion, which is more convenient in transaction processing (TP) business. But these tools cannot assemble too complex SQL, are not suitable for reporting business, and are also difficult to integrate with reporting tools.
There seems to be no universal solution for directly converting one database SQL to another (such as from Oracle to MySQL). If functions in SQL statements can be written according to a certain standard and then converted into various database syntax, esProc SPL provides a lightweight solution. The SPL translation function can convert standard SQL statements using this convention in reports or applications into SQL statements of different databases and have them executed by the databases.
SPL is developed in Java and can be integrated into reporting tools through jar package embedding. SPL is responsible for SQL translation between reports and databases.
When using it specifically, there is no need for report developers to write any code, just change the SQL in the report to this standard SQL at one time. The translation of SQL will be automatically handed over to SPL’s JDBC gateway for processing: the report is connected to SPL through JDBC, and all SQL statements received through JDBC will be submitted to the gateway by default. The gateway is programmable and can implement automatic translation by writing simple SPL scripts. Except for changing the report SQL statements to a unified standard syntax, no other parts need to be modified (integration and gateway writing are one-time operations), and the overall change is small enough to implement the goal of cross-database SQL migration.
For example, after converting the report SQL of order status within 30 days to standard statement:
SELECT SUM(total_amount) AS total_sales, COUNT(*) AS total_orders
FROM orders
WHERE order_date >= ADDDAYS(NOW(),-30);
When the database types are different, SQL will be automatically translated into different writing styles.
ORACLE:
SELECT SUM(total_amount) AS total_sales, COUNT() AS total_orders
FROM orders
WHERE order_date >= SYSDATE - 30;
SQLSVR:
SELECT SUM(total_amount) AS total_sales, COUNT() AS total_orders
FROM orders
WHERE order_date >= DATEADD(DAY, -30, GETDATE());
MYSQL:
SELECT SUM(total_amount) AS total_sales, COUNT() AS total_orders
FROM orders
WHERE order_date >= DATEADD(DAY, -30, GETDATE());
POSTGRES:
SELECT SUM(total_amount) AS total_sales, COUNT() AS total_orders
FROM orders
WHERE order_date >= NOW() - INTERVAL ‘30 DAYS’;
When switching databases, you only need to change the database type and database connection in the configuration, and in most cases, it can be seamlessly migrated. The databases and functions supported by SPL can also be extended, so you don’t have to worry about not having enough.
If encountering more complex special situations, such as Oracle’s KEEP function, many other databases do not have it. If this function is used in the SQL statement, it cannot be migrated to other databases using the simple method mentioned above. In this case, you can use basic SQL to read data only, and more complex operations can be implemented in SPL. SPL has comprehensive computing capabilities and is completely independent of databases, so the code written can continue to be migratable.
Judith_677
I really do want to give them big belly rubs! This is just so inviting!
Judith_677
He is a hard-working quality inspector, making sure the blanket is absolutely soft and ready to use.
Judith_677
God, bet he's gonna catch many bad guys and protect the town!
Judith_677
This is literally ME trying to survive winter. But I don't get such a perfectly-tailored blanket..
Judith_677
wow, they really know how to accomplish this job excellently!
Judith_677
Thanks for sharing! I agree—SPL esProc can be surprisingly efficient once you get the hang of it. It offers some great functionalities for manipulating large datasets that are worth exploring. Have you used it yourself? Would love to hear about your experience!
Judith_677
Hi, thanks for bringing up SPL esProc! You’re right—currently, there are fewer English-speaking users, which is why it might be hard to find user experiences in English. However, it’s widely used by a significant number of Chinese users for its powerful data manipulation capabilities, especially when it comes to handling large Excel spreadsheets.
If you’re curious to explore more, here are some real-world examples of how it’s used: https://c.scudata.com/tag/Desktop.
Give it a try! You might find it surprising, and if you have any questions or need help, feel free to ask!
Judith_677
=spl("=?1.conj(~.group((#-1)\6)).count( ~.contain( ?2,?3) )",$C$1:$V$8,$B13,C$11)
Judith_677
=spl("=E@p(E@1(?).group(int(~.split($[.])(2))\64))",A1:A18)
Judith_677
=spl("=E@b(?.news((t=~4,100.iterate@a(30000,,!if(t>50000,t-=30000))|t);?.~1,?.~2,?.~3,~))",A2:D7)
Judith_677
=spl("=?.group(~).select(~.len()==1).conj()",A1:G7)
Judith_677
=spl("=E@2p(E@2p(?).(~.group((#-1)\3).(~.select(~).concat("" ""))))",A2:E10)
Judith_677
=spl("=?.group((#-1)\2).(~1(1)|~2(2)|~1(3))",A1:C8)
He is an absolute dream! At 11 weeks old, he's already stealing hearts with that little face. Hope you have a million more precious moments with your little fur baby!