Universal Server: DataBlade API or CLI
Posted in 1999
Topics: Stored Procedures & SPL, Connectivity: ODBC / JDBC / .NET
We are thinking of upgrading from 7 to 9 on NT. The only reason is to move some stored procedures from SPL to C. Assuming we do not use Blades or Smart Large Objects, should we consider moving our existing ODBC/CLI based link to DataBlade API? Is it faster / slower and harder / easier to implement? Our clients are VB and C. Thanks Bashar Chalabi CTL, London
Bashar Chalabi (bashar@ctl.com) wrote: : We are thinking of upgrading from 7 to 9 on NT. The only reason is to move : some stored procedures from SPL to C. Assuming we do not use Blades or Smart : Large Objects, should we consider moving our existing ODBC/CLI based link to : DataBlade API? Is it faster / slower and harder / easier to implement? Our : clients are VB and C. Two opinions: First, I doubt that moving SPL stored procedures to 'C' will help you all that much (unless your procedures are **really** complicated). This is because, regardless of whether you're in 'C' or in SPL, the SQL you run is the same, and often that's the biggest cost in the whole thing. OTOH, it's common to have to do some wierd things in SPL to achieve certain results. For example; (pseudo-code) FOREACH h,i,j,k IN ( SELECT Performance, HireDate, Salary, Id FROM Employees ) LET NewSalary = SomeComplexProcedure ( Performance, HireDate, Salary); UPDATE Employees SET Salary = NewSalary WHERE Id = k; END FOREACH; In this case, simply by re-implementing SomeComplexProcedure() as a 'C' UDR (taking advantage of the extensibility), you can turn this set of procedural logic above into: UPDATE Employees SET Salary = SomeComplexProcedure ( Performance, HireDate, Salary); This will go faster than the SPL, and it also means that you can do the following kinds of queries a the drop of a hat: SELECT SUM( SomeComplexProcedure( Performance, HireDate, Salary) - Salary) FROM Employees; Second, I would stick to the CLI/ODBC interface for external programs. There are unlikely to be any significant performance improvements moving to SAPI, and if the code you have works then why bother changing it? KR Pb