October 14, 2009 at 3:39 am
I asked our vendor about some performance issues, especially regarding the SQL connections from the application. This is the response I got. Does this seem a reasonable way of doing things ?
"The application has one connection for normal read/create/update/delete commands using manual transaction processing, one for read/create/update/delete commands on selected tables using automatic transaction processing (allowing committals to these tables within a manual transaction on the first connection) and a third for read only enquiries. It can also utilise a fourth for SQL pass through when the first is not available (usually used only during initial startup). The change in the new version is to have the 3 main connections permanently open whilst the application is running, instead of repeatedly opening and closing them. We have also ensured that these connections are used in all cases and further connections are not opened, as could happen in the past."
October 14, 2009 at 11:16 am
I guess it depends on the type of processing the application is doing. What technology the application is written in? By the look of this design one might think the main design is at least 10 years old, when connection pooling wasn't the preferred way of managing connections. It sounds also there are some client-side cursors or loops that process data row by row.
Regards
Piotr
...and your only reply is slàinte mhath
October 15, 2009 at 1:55 am
The application was written is FoxPro, initially using a Fox backend. However they moved to a SQL backend with very little recoding. We are finding performance is shocking though.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply