TECHNOLOGY OVERVIEW

Unlike some non-tunable systems on the market today claiming to be “Customs Certified,” our software employs true client/server architecture to optimize the distribution of the processing workload between client and server, resulting in increased performance and flexibility.  We employ both intelligent clients and intelligent servers, with logic on both the front end (source codes inherent in client application) and the back end (source codes incorporated into the SQL DB server, i.e. SQL-based stored procedures).  Click here to see performance comparison chart.

What is a SQL-based Stored Procedure?

The expression Stored Procedure comes from the SQL-based Server world. When a client workstation sends a request to a SQL-based server, it actually sends a plain text request in SQL language to the SQL-based server. This request is then parsed and interpreted on the SQL-based server before being executed. Obviously, if the source code of the request is huge and if the request is sent multiple times during a session, there is a great deal of time spent in sending the source code over the network, parsing and interpreting the request as many times as the request is sent.

So, the idea was to find a way to send that request over the network, parse and interpret it once, and then execute it only each time it was received from a client workstation. The solution was to keep the request source code (in other words, a procedure) on the server side and have the client workstation send a request consisting only of the name of the procedure to be executed. The procedure is consequently said to be "stored" on the server, thus the term "stored procedure."

Note that a SQL-based stored procedure is a procedure that can receive parameters from a client workstation, execute the tasks it implements (synchronously or asynchronously) and eventually return a result to the client workstation. When a client workstation invokes the execution of a stored procedure, to a certain extent, it delegates code execution on the server machine.

Since SQL-based Store Procedures minimizes communications across the network, performance is then maximized?

Precisely.  This method will maximize performance since the database(back-end) will process all communication-intensive logics, versus the old traditional way where all logics reside in the application(front-end) and are constantly communicating with the database (to exchange information) before it completes one transaction.  What this means on the local-area-network (LAN) most importantly, the wide-area-network (WAN) is that applications that doesn’t utilize store procedures will quickly eat up network bandwidth,  utimately, leading to an application that offers no true solutions for enterprise scability, with the large and growing number of users in mind.  In short, an application that is inoperable in a large scale environment.

In summary, Client/Server is more than just having a back-end (server) and a client(front-end).  True Client/server systems place functions where they should optimally reside on the network, reducing network communications traffic and maximizing performance.  True Client/server systems also utilize a powerful relational database, boosting data integrity and security across the entire enterprise.