Database'den Data SeçmeSelecting Data From Database

This page is part of an incremental translation project. Body text not yet translated to Turkish falls back to English even in TR mode.

Business seviyesi bir programlama dili olarak, TROIA database'lerle yüksek collaboration'a sahiptir. TROIA ile farklı database'lere bağlanma, database transaction'larını yönetme veya SQL query'leri çalıştırma gibi çok sayıda operation gerçekleştirmek mümkündür. Bu bölüm, TROIA'da database konseptinin temellerini ve select statement'ı tanıtmayı amaçlar.As a business level programming language, TROIA has high collaboration with databases. With TROIA it is possible to perform too many operations on databases, such as connecting different databases, managing database transactions or executing SQL queries. This section aims to introduce basics of database concept in TROIA and select statement.

SELECT KomutuSELECT Command

Database'de bir select query'si çalıştırmak, tüm dataset'i fetch etmek ve seçilen data'yı bir table symbol'üne atamak için SELECT komutunu kullanmalısınız. SELECT komutu SQL'in select komutuna çok benzer ve where condition'ları, distinct, inner/outer join'ler, system function'lar, group by ve order by gibi hemen hemen her şeyi destekler. Ama bu, TROIA'nın SELECT komutunun SQL'in select komutuyla aynı olduğu anlamına gelmez, farklı davranışları, feature'ları ve bazı ortak davranışlar için kendi yöntemleri vardır. SELECT komutu hakkında bilinmesi gereken en önemli şeylerden biri, TROIA SELECT komutunun runtime'da bağlı database sistemine (Oracle, MsSql, MySql, PostgreSql vb.) göre yorumlanıp cross database query'leri oluşturmak için SQL Select statement'larına dönüştürülmesidir.To run a select query on database, fetch all dataset and assign selected data to a table symbol, you must use SELECT command. SELECT command is very similar to SQL’s select command and supports almost all stuff like where conditions, distinct, inner/outer joins, system functions, group by and order by etc. But this does not mean that SELECT command of TROIA is identical with the SQL’s select command, they have different behaviors, features and their own way for some common behavior. One of the most important things to know about SELECT command is that TROIA SELECT command is interpreted and converted to SQL Select statements considering connected database system (Oracle, MsQql, MySql, PostgreSql etc.) on runtime to create cross database queries.

İşte SELECT komutunun temel syntax'ı:Here is the basic syntax of SELECT command:

SELECT [ALL | DISTINCT] {selectlist}
        FROM {table} [, {othertables}]
        [INNER | OUTER JOIN {jointable} ON {onclause}]
        [WHERE {condition}]
        [ORDERBY {orderbycolumns} [ASC | DESC]]
        [INTO {targettable}]
        [ROWFETCHSTART {fetchstart}]
        [ROWFETCHLIMIT {fetchlimit}]
        [WITHCONTROL {rowcount}]
        [WITHCACHE]

Görebileceğiniz gibi, standart bir SQL syntax'ına çok benzer ama yine de bazı özel farklar vardır. Farklardan biri ORDER BY keyword'üyle ilgilidir. TROIA'da "ORDER BY" yerine ORDERBY kullanmalısınız. Aslında, standart olan yerine ORDERBY kullanmak sadece troia platformunun eski sürümlerinden gelen bir TROIA geleneğidir, ORDER BY da yeni interpreter tarafından desteklenir. Aralarında fark olmasa da, çoğu troia programcısı hâlâ boşluk karakteri olmayanı kullanır.As you can see, it is very similar to a standard SQL syntax but still there are some special differences. One of the differences is about ORDER BY keyword. In TROIA you must use ORDERBY instead of “ORDER BY”. Honestly, using ORDERBY instead of standard one is just a TROIA tradition which comes from old versions of troia platform, ORDER BY is also supported by new interpreter. Even though there is no difference between them, most of troia programmers still uses the one without space character.

INTO keyword'ü sadece target table variable'ını belirtmek içindir. SELECT komutu seçilen data'yı target table'a atar. Target table verilmemişse, SELECT komutu seçilen database table'ının ismiyle bir table variable'ı oluşturur.INTO keyword is just for indicating the target table variable. SELECT command assigns selected data to target table. If target table is not given, SELECT command creates table variable with the name of selected database table.

ROWFETCHSTART / ROWFETCHLIMIT keyword'leri, MySQL'in LIMIT ve OFFSET keyword'lerine çok benzer. ROWFETCHSTART komutu, fetch etmeye başlamak için bir tür shift veya offset'tir; örneğin ROWFETCHSTART olarak 10 geçirirseniz, ilk dokuz record yok sayılır ve fetch işlemi onuncu satırdan başlar. ROWFETCHLIMIT, fetch edilen satır sayısını sınırlar, ama tabii ki verilen sayıdan daha fazla satır varsa. Bu keyword'leri birlikte veya tek başına kullanmak mümkündür. Bu iki keyword için önemli nokta, bunların tamamen application server katmanında ele alınmasıdır, başka bir deyişle database MySql gibi benzer bir davranışı desteklese bile database server'a gönderilen SQL query'sini etkilemezler.ROWFETCHSTART / ROWFETCHLIMIT keywords are very similar to MySQL’s LIMIT and OFFSET keywords. ROWFETCHSTART commands just a kind of shift or offset to start fetching, for example if you pass 10 as ROWFETCHSTART, first nine records are ignored and fetching starts from tenth row. ROWFETCHLIMIT limits fetched row count, but of course if there are more rows than the given number. It is possible to use these keywords together or each one alone. Important point for these two keyword is that, they are totally handled on application server layer, in other words they are not affect SQL query sent to database server even if database supports a similar behavior like MySql.

WITHCONTROL varyasyonu; select statement'ınız verilen satır sayısından daha fazla satır seçerse, server ve client tarafında olası memory sorunlarını önlemek için sistem client'a döner ve kullanıcıdan select operation'ını gerçekleştirmesini veya iptal etmesini ister.WITHCONTROL variation, if your select statement selects more rows than given row count system returns to client and asks user to perform or cancel select operation to avoid possible memory problems on server and client side.

WITHCACHE bir performance optimization parametresidir, ilerleyen bölümlerde ele alacağız.WITHCACHE is a performance optimization parameter, we will discuss it on next sections.

İşte hardcode bir where condition ile maksimum password validity'ye sahip on kullanıcıyı seçen ve son table'ı bir table variable'a atayan örnek bir select statement.Here is a sample select statement selects ten users who have maximum password validity with a hardcode where condition and assigns final table to a table variable.

OBJECT:
        TABLE TABLEVARIABLE,
        INTEGER ROWCOUNT;

SELECT CLIENT, USERNAME, PWDVALIDITY
        FROM IASUSERS
        WHERE CLIENT = '00'
        ORDER BY PWDVALIDITY DESC
        ROWFETCHLIMIT ROWCOUNT
        INTO TABLEVARIABLE;

SQL System Variable'ıSQL System Variable

Bir database query'si çalıştırıldığında, sistem otomatik olarak query'yi SQL'e ayarlar, bu yüzden nihai database query'sini SQL system variable'ından okumak mümkündür. Bu davranış SELECT, DELETE, UPDATE ve INSERT komutları için aynıdır. Ayrıca, INSERTSQL, UPDATESQL, DELETESQL komutları, database'de query çalıştırmadan bu SQL system variable'ını ayarlar. Çoğunlukla SQL script'leri oluşturmak için kullanılırlar.When a database query is executed, system automatically the query is set to SQL, so it is possible to read final database query from SQL system variable. This behavior is same for SELECT, DELETE, UPDATE and INSERT commands. Additionally, INSERTSQL, UPDATESQL, DELETESQL commands sets this SQL system variable without running query on database. They are mostly used for creating SQL scripts.

İşte SQL system variable'ının değerini okuyabileceğiniz örnek bir TROIA kodu.Here is a sample TROIA code that you can read value of SQL system variable.

OBJECT:
        TABLE TABLEVARIABLE,
        INTEGER ROWCOUNT,
        STRING STRINGVAR3;

SELECT CLIENT, USERNAME, PWDVALIDITY
        FROM IASUSERS
        WHERE CLIENT = '00'
        ORDER BY PWDVALIDITY DESC
        ROWFETCHLIMIT ROWCOUNT
        INTO TABLEVARIABLE;

STRINGVAR3 = SQL;

SQL System variable'ı, TROIA database komutlarının davranışını öğrenirken kullanabileceğiniz faydalı bir system variable'ıdır.SQL System variable is useful system variable that you can use while learning behavior of TROIA database commands.

WHERE Condition'da Troia Variable'ları KullanmaUsing Troia Variables on WHERE Condition

SELECT statement'larında TROIA variable'larını kullanmak da mümkündür. Interpreter, data type'ı dikkate alarak variable'larınızı otomatik olarak nihai query'ye bind eder. İşte WHERE condition'ında troia variable'ları içeren örnek bir TROIA kodu. Önceki bölümlerde tartıştığımız gibi nihai SQL statement'ını SQL system variable'ından analiz edebiliriz.It is also possible to use TROIA variables in SELECT statements. Interpreter automatically binds your variables to final query considering data type. Here is a sample TROIA code that contains troia variables in it’s WHERE condition. As we discussed in previous sections we can analyze final SQL statement from SQL system variable.

OBJECT:
        TABLE TABLEVARIABLE,
        STRING NAMEPREFIX,
        STRING STRINGVAR3;

        NAMEPREFIX = 'a%';


SELECT CLIENT, USERNAME, PWDVALIDITY
        FROM IASUSERS
        WHERE CLIENT = SYS_CLIENT AND USERNAME LIKE NAMEPREFIX
        ORDER BY PWDVALIDITY DESC
        INTO TABLEVARIABLE;

STRINGVAR3 = SQL;

Bind edilen variable'ların boyutu, sayısı veya type'ıyla ilgili herhangi bir kısıtlama yoktur.There is not any limitation related with the size, count or type of bound variables.

Varsayılan olarak, database server'a geçirilen SQL statement'ı SQL variable'ının içeriğiyle aynıdır. Alternatif bir bind yöntemi olarak sistem, application server'ın server configuration (server settings) dosyasında tanımlanan database configuration satırına bağlı olarak "prepared" seçeneğini kullanabilir. Bu "prepared" seçeneğinde, SQL variable'ı database'e geçirilen SQL statement'ına ek olarak oluşturulur.As default, SQL statement that passed to database server is same with the content of SQL variable. As an alternative binding method system can use “prepared” option, due to database configuration line which is defined on server configuration (server settings) file of application server. In this “prepared” option, SQL variable is builded in addition to SQL statement that is passed to database.

Karmaşık Select Statement'larıComplex Select Statements

Normal SELECT statement'larında select komutunun yapısı açıkça tanımlanır. Başka bir deyişle, normal bir SELECT statement'ında column listesi, table ismi/isimleri ve where condition'ı sabittir ve programcı tarafından development time'da okunabilir. Tek dynamic içerik runtime'da bind edilecek variable'lardır ve bu variable'lar SELECT statement'ının yapısını değiştirmez.In regular SELECT statements the structure of select command is defined explicitly. In other words, in a regular SELECT statement column list, table name(s) and where condition are constants and they can be read on development time by the programmer. The only dynamic content is variables that will be bound on runtime and this variables does not change the structure of SELECT statement.

Ama bazı durumlarda, SELECT statement'ının bazı yapısal parçaları dynamic'tir ve nihai select statement'ı runtime'da tanımlanır. Bu tür implicit SELECT komutlarına TROIA jargonunda "complex select" denir. Aşağıdaki örnek, dynamic column listesi, where condition'ı ve table ismi içeren karmaşık bir SELECT statement'ını gösterir. Tabii ki yalnızca bir dynamic parça kullanmak da mümkündür.But in some cases, some structural parts of SELECT statement are dynamic and final select statement is defined on runtime. This kind of implicit SELECT commands are called “complex select” as a TROIA jargon. Example below, shows a complex SELECT statement that contains dynamic column list, where condition and table name. Of course it is possible to use only one dynamic part.

OBJECT:
        STRING SELECTITEMSLIST,
        STRING FROMTABLENAME,
        STRING WHERECONDITION,
        STRING STRCREATEDBY,
        TABLE TMPTABLE;

SELECTITEMSLIST = 'USERNAME, PASSW, CREATEDBY, CREATEDAT';
FROMTABLENAME = 'IASUSERS';
WHERECONDITION = 'CREATEDBY = STRCREATEDBY';
STRCREATEDBY = 'btan';
/**/
SELECT @SELECTITEMSLIST
        FROM @FROMTABLENAME
        WHERE @WHERECONDITION
        INTO TMPTABLE;

Bu örnekte, hiçbir variable ismi önceden tanımlanmamıştır; bu yüzden programcılar column listesini, table ismini ve where condition'ını belirtmek için herhangi bir variable ismi kullanabilir. Ama bazı durumlarda, select statement'ının ilk kısmı açıkça tanımlanırken, programcıların WHERE condition'ına dynamic bir condition eklemesi gerekebilir. Bu tür durumlarda, TROIA programcıları önceden tanımlı bir additional condition variable'ı olan SYSADDITIONALCRITERIA system variable'ını kullanmalıdır. İşte SYSADDITIONALCRITERIA variable'ının nasıl kullanılacağını gösteren bir örnek.In this example, none of the variable names are predefined; so programmers can use any variable name to indicate column list, table name and where condition. But in some cases, while first part of select statement is defined explicitly, programmers may need add an dynamic condition to WHERE condition. In this kind of cases, TROIA programmers have to use SYSADDITIONALCRITERIA system variable which is predefined additional condition variable. Here is an example that shows how to use SYSADDITIONALCRITERIA variable.

OBJECT:
        STRING FROMTABLENAME,
        STRING STRCREATEDBY,
        TABLE TMPTABLE;

FROMTABLENAME = 'IASUSERS';
SYSADDITIONALCRITERIA = 'AND CREATEDBY = STRCREATEDBY';
STRCREATEDBY = 'btan';
/**/
SELECT USERNAME, PASSW, CREATEDBY, CREATEDAT
        FROM @FROMTABLENAME
        WHERE CLIENT = SYS_CLIENT @SYSADDITIONALCRITERIA
        INTO TMPTABLE;

Select item listesi ve from table isminde explicit ve implicit parçaları birlikte kullanmaya izin verilmez. Bu sadece SYSADDITIONALCRITERIA system variable'ı ile WHERE condition'ı için geçerlidir.It is not allowed to combine explicit and implicit parts together on select items list and from table name. It is just allowed for WHERE condition with SYSADDITIONALCRITERIA system variable.

Karmaşık SELECT Statement'larının PerformansıPerformance of Complex SELECT Statements

Diğer TROIA komutları gibi SELECT statement'ları da convert process'inde parse edilip yorumlanır (daha fazla bilgi için Language Basics Bölümüne bakınız). Converting bir development time operation'ı olduğundan, runtime'da zaman harcamaz. Karmaşık SELECT statement'larına gelince, nihai select statement'ı runtime'da oluşturulduğundan tüm yorumlama işlemi runtime'da gerçekleştirilir. Bu yüzden, karmaşık SELECT statement'ları kullanmak, sınırlı olsa da application performance'ını etkileme potansiyeline sahiptir.Like other TROIA commands SELECT statements are parsed and interpreted on convert process (for more information please see Language Basics Section). Since converting is a development time operation, it does not consume time in runtime. When it comes to complex SELECT statements, all interpreting operation is performed on runtime, because final select statement is builded on runtime. Therefore, using complex SELECT statements has a potential to effect application performance, although it has a limited.

Kısacası, karmaşık SELECT bazı operation'ları kolaylaştırsa da, application performance'ı üzerinde olumsuz bir etkiye sahiptir, bu yüzden gereksiz olduğunda bu tür statement'ları kullanmak önerilmez.Briefly, although complex SELECT eases some operations, it has a negative effect on application performance, so it is not recommended to use these kind of statements when they are unnecessary.

Manuel Fetch EtmeFetching Manually

SELECT komutu, select operation'ının tüm adımlarını atomik bir şekilde gerçekleştirir. Ama bazı durumlarda seçilen data devasa olabilir ve tüm data'yı fetch etmek çok fazla memory harcayabilir. Devasa bir table'ın her satırı için belirli bir operation gerçekleştireceğinizi ve bu devasa data'yı memory'de fetch edip saklamanıza gerek olmadığını varsayın. Bu durumda, database'de select query'sini çalıştırıp data'yı satır satır fetch etmelisiniz. Bu tür bir operation gerçekleştirmek için SELECT komutu yerine SELECTLINE ve FETCH komutlarını kullanmalısınız. SELECT komutunun aksine, SELECTLINE komutu seçilen data'yı fetch etmez ve satırları fetch etmek için FETCH komutunu bekler. Tahmin edebileceğiniz gibi, FETCH komutu her çalıştırmada result set'ten tek bir satırı table'a fetch eder.SELECT command performs all steps of select operation in an atomic way. But in some cases selected data is huge and fetching all data may consume too much memory. Assume that you will perform a specific operation for each row of a huge table and you don’t need to fetch and store this huge data in memory. In this case you must run select query in database and fetch data row by row. To perform this kind of operation you must use SELECTLINE and FETCH commands instead of SELECT command. On the contrary of SELECT command, SELECTLINE command does not fetches selected data and waits for the FETCH command to fetch rows. As you can predict, FETCH command fetches a single row from result set to table on each execution.

SELECTLINE statement'ının syntax'ı isim dışında tamamen aynıdır, bu yüzden SELECT komutuna benzer karmaşık SELECTLINE statement'ları kullanmak mümkündür. Aşağıdaki örnekte, tüm result set üzerinde loop yaparken, table her iterasyonda yalnızca tek bir satır içerir. Lütfen SELECT ve LOOP komutunu kullanarak benzer bir kod yazın ve STRINGVAR3'ün değerini tartışın.Syntax of SELECTLINE statement is totally same except the name, so it is possible to use complex SELECTLINE statements similar to SELECT command. At the example below, while looping on whole result set, table contains only single row at each iteration. Please write a similar code using SELECT and LOOP command and discuss the value of STRINGVAR3.

OBJECT:
        STRING STRINGVAR3,
        TABLE TMPTABLE;

STRINGVAR3 = '';
/**/
SELECTLINE USERNAME, PASSW, CREATEDBY
        FROM IASUSERS
        WHERE CLIENT = SYS_CLIENT AND CREATEDBY = 'btan' INTO TMPTABLE;

WHILE 1
BEGIN
        FETCH TMPTABLE;
        IF SYS_STATUS THEN
           BREAK;
        ENDIF;
        /** do something with the row */
        STRINGVAR3 = STRINGVAR3 + TMPTABLE_ROWCOUNT + ' ' + TMPTABLE_USERNAME + TOCHAR(10);
ENDWHILE;

SET TMPTABLE TO TABLE TMPTABLE;

Seçilen result set'in satırları üzerinde operation'ı block block gerçekleştirmek isterseniz, fetch komutu ayrıca verilen satır boyutuyla block'lar halinde fetch etmeyi de destekler. Bu özellik yalnızca 8.02.01 090301 ve sonraki sürümlerde desteklenir. İşte FETCH komutunun mevcut tüm syntax seçenekleri.If you want to perform the operation block by block on the rows of the selected result set, fetch command has also supports fetching in blocks with the given row size. This feature is only supported on 8.02.01 090301 and following versions. Here is the whole available syntax options of FETCH command.

FETCH {tablename}
FETCH {tablename} SIZE {rowcounttofetch}

Database'e Özgü Syntax & Function'larDatabase Specific Syntax & Functions

Önceki başlıklarda belirtildiği gibi, TROIA SQL komutları SQL komutlarıyla aynı değildir. Bunlar sadece kullanıcının bağlı olduğu database sistemini dikkate alarak sql statement'larına yorumlanan TROIA komutlarıdır. Başka bir deyişle, kullanıcı X database sistemine (MySQL, Oracle, MSSQL vb.) bağlıysa, sistem SELECT komutunu X ile uyumlu geçerli bir select statement'ına dönüştürür.As mentioned on previous titles, TROIA SQL commands are not identical to SQL commands. They are just TROIA commands that are interpreted to sql statements considering database system that user is connected. In other words, if user is connected to X database system (MySQL, Oracle, MSSQL etc.), system converts SELECT command to a valid select statement compatible with X.

Bir örnekle tartışalım. Database katmanında string concatenation'a izin veren CONCAT function'ı MySQL'de desteklenir, ama MSSQL'de + operatörü ve Oracle'da || operatörleri string variable'ları birleştirir. TROIA application'larında developer'lar CONCAT() function'ını kullanmak zorundadır ama sistem bunu MSSQL connection'larında + operatörüne, Oracle connection'larında || operatörüne dönüştürür. Bu yüzden birden fazla database sistemini desteklemek için TROIA code'unda manipülasyon yapmaya gerek yoktur. Aşağıdaki liste, farklı database sistemlerini desteklemek için TROIA interpreter tarafından manipüle edilen bazı özel function isimlerini içerir. Bu liste tüm özel function isimlerini içermez, daha fazla bilgi ve güncel liste için lütfen ilgili help dokümanlarına bakınız.Lets discuss it with an example. CONCAT function which allows string concatenation on database layer and it is supported on MySQL, but in MSSQL + operator and in Oracle || operators concatenate string variables. In TROIA applications developers have to use CONCAT() function but system converts it to + operator on MSSQL connections and || on Oracle connections. So there is no need to make manipulations on TROIA code to support multiple database systems. The list below contains some special function names that is manipulated by TROIA interpreter to support different database systems. This list is does not contains all special function names, for more information and up to date list please see help related help documents.

CONCAT()            DATEPART()
SUBSTRING()         DATEDIFF()
LEFT()              YEAR()
MONTH()             DAYOFMONTH()
QUARTER()           DAYOFYEAR()
MINUTE()            HOUR()
DATEADD()           WEEK()
LEN()               DATESUB()

İşte interpreter'ın database sistemini dikkate alarak özel function'ları nasıl manipüle ettiğini gösteren daha somut bir örnek. Tablo, kodda SELECT statement'ının sonucu olarak farklı database sistemleri için nihai SQL query'sini içeren STRINGVAR3 variable'ının değerini gösterir.Here is a more concrete example that shows how interpreter manipulates special functions considering database system. The table shows the value of STRINGVAR3 variable which contains the final SQL query for different database systems as a result of SELECT statement in the code.

OBJECT:
        TABLE T1,
        STRING STRINGVAR3;

SELECT YEAR(CREATEDAT) AS YEARCOLUMN
        FROM IASUSERS
        INTO T1;

STRINGVAR3 = SQL;
MSSQLSELECT YEAR(CREATEDAT) AS YEARCOLUMN FROM IASUSERS
PostgreSQLSELECT CAST(EXTRACT(YEAR FROM CREATEDAT) AS INTEGER) AS YEARCOLUMN FROM IASUSERS
MySQLSELECT YEAR(CREATEDAT) AS YEARCOLUMN FROM IASUSERS

Farklı database sistemlerinde function'lardaki uyumsuzluk durumlarının yanı sıra, çeşitli farklılık türleri de vardır. Başka bir örnek, Oracle'ın NULL ve boş string değerleri için 'IS' ve '=' operatörlerinin davranışıdır. Bu tür uyumsuzluk durumları troia interpreter tarafından ele alındığından, belirli bir database sistemi için farklı kodlar implement etmek, olası performans ve code transfer sorunları nedeniyle önerilmez.Besides incompatibility cases on functions on different database systems, there are various types of differences. Another example is behavior of ‘IS’ and ‘=’ operators of Oracle for the NULL and empty string values. Since such incompatibility cases are handled by troia interpreter, implementing different codes for a specific database system is not recommended because of possible performance and code transfer problems.

Index'leri ZorlamaForcing Indexes

TROIA komutlarından database engine'i belirli bir index kullanmaya zorlamak önerilmese de, SELECT ve SELECTLINE komutlarında bir index ismi belirtmek teknik olarak mümkündür. İşte bir index'i zorlamak için bir örnek:Although it is not recommended to force database engine to use a specific index from TROIA commands, it is technically possible to indicate an index name on SELECT and SELECTLINE commands. Here is an example to force an index:

SELECT * FROM IASUSERS (INDEX=indexname) WHERE CLIENT = SYSCLIENT AND ...

TROIA interpreter, bu syntax'ı otomatik olarak bağlı database'in izin verdiği syntax'a dönüştürür. Örneğin, MySQL database connection'larında "FORCE INDEX" syntax'ına dönüştürülür.TROIA interpreter, automatically converts this syntax to the syntax that connected database allows. For example, in MySQL database connections it is converted to “FORCE INDEX” syntax.

Application Performance ve Database Operation'larıApplication Performance and Database Operations

Diğer benzer programlama dilleri gibi, database operation'larının TROIA'da application performance'ı üzerinde büyük etkisi vardır. Database ile ilgili performans darboğazları, database configuration'ı, table indexing (yanlış indexing) veya query (etkisiz query) gibi farklı katmanlarda olabilir.Database operations have huge affect on application performance in TROIA, like other similar programming languages. Database related performance bottlenecks may be in different layers such as database configuration, table indexing (wrong indexing) or the query (ineffective query).

Query seviyesi performans sorunları, select statement'ınızın yapısıyla ilgili olabilir. Bu tür sorunlardan kaçınmak için, process'inizin gereksinimlerini dikkate alarak mümkün olduğunca en basit ve en etkili select statement'ını yazdığınızdan emin olmalısınız. Kullanışsız veya zaten var olan bir data'ya erişmek için en iyi SELECT statement'ına sahip olsanız bile, bu cpu zamanınızı tüketecektir. Bu yüzden, bazı durumlarda sadece yapılarını değil, SELECT statement'larınızın varlığını bile eleştirmeniz gerekir.Query level performance problems may be related with the structure of your select statement. To avoid these kind of problems you must be sure that you wrote the simplest and most effective select statement as much as possible considering requirements of your process. Even if you have the best SELECT statement to access a useless or already existing data, it will consume your cpu time. Therefore, in some cases you have to criticize even the existence of your SELECT statements, not only structure of them.

WITHCACHE Seçeneği (Database Selection Cache)WITHCACHE Option (Database Selection Cache)

Bazı durumlarda, TROIA programcıları beklenen sonuç aynı olsa bile aynı SELECT statement'larını birden fazla kez geçirir. Bu tür performans darboğazlarını kısa vadede çözmek için WITHCACHE varyasyonu bir seçenektir. WITHCACHE seçeneğini kullanırsanız, SELECT statement'ının sonucu interpreter tarafından cache'lenir ve SELECT statement'ı tekrar çalıştırıldığında aynı sonuç kullanılır.In some cases, TROIA programmers passes same SELECT statements more than once even the expected result is same. To solve this kind of performance bottlenecks in short term, WITHCACHE variation is an option. If you use WITHCACHE option, the result of SELECT statement is cached by the interpreter and same result is used when SELECT statement is performed again.

Aşağıdaki örnekte, ilk block'un her iki SELECT statement'ı da database'e erişir ve database'de ilgili select query'sini çalıştırır, ama ikinci block'ta, ilk select database katmanında çalıştırılır ve sonuç cache'lenir, ardından ikinci SELECT statement'ı database'e erişmeden cache'lenmiş sonucu kullanır.In the example below, both SELECT statements of first block access database and executes corresponding select query on database, but in second block, first select is executed on database layer and the result is cached, then second SELECT statement uses the cached result without accessing database.

/* Block 1 */
SELECT * FROM IASUESERS WHERE CLIENT = SYS_CLIENT;
SELECT * FROM IASUESERS WHERE CLIENT = SYS_CLIENT;

/* Block 2 */
SELECT * FROM IASUESERS WHERE CLIENT = SYS_CLIENT AND USERNAME = SYS_USER WITHCACHE;
SELECT * FROM IASUESERS WHERE CLIENT = SYS_CLIENT AND USERNAME = SYS_USER WITHCACHE;

Bu tür database access girişimleri çoğunlukla head table ile ilgili data almak için item table'larının loop statement'larında kullanılır. Ama gerçek head record tüm item'lar için aynıdır ve select query sonucu da aynıdır. Bu tür durumlar için en iyi practice, head data'yı seçmemektir, ama bazı durumlarda WITHCACHE seçeneği programcıların mevcut kodu kolayca refactor etmesine olanak tanır. Alternatif bir çözüm varsa WITHCACHE seçeneğini kullanmak önerilmez.This kind of database access attempts are mostly used on loop statements of item tables to get data related with the head table. But the actual head record is same for all items and the select query result is same as well. The best practice about this kind of situations is not selecting head data, but in some cases WITHCACHE option allows programmers to refactor existing code easily. It is not recommended to use WITHCACHE option if there is an alternative solution.

WITHCACHE seçeneğine sahip ilk SELECT statement'ı tarafından oluşturulan database selection cache'leri, yalnızca bir session için ve yalnızca bir user interaction sırasında geçerlidir. Başka bir deyişle, bir session bir select statement'ı için data cache'lerse, bu cache aynı query için aynı database connection'ı kullansalar bile başka session'lar tarafından kullanılamaz. Ve action bittiğinde, sistem button tıklama gibi yeni bir user interaction için client tarafına döndüğünde bu cache'ler temizlenir. Ayrıca, TROIA programcılarının cache'i temizlemesi gerekiyorsa CLEARDBSELECTIONCACHE() TROIA function'ı tüm cache'lenmiş data'yı kaldırır.Database selection caches which are created by the first SELECT statement that has WITHCACHE option, is valid for only one session and during only one user interaction. In other words, if a session caches data for a select statement, this cache cannot be used by other sessions even if they use same database connection for the same query. And this caches are cleared when action ends system returns to client side for a new user interaction like clicking button etc. Additionally, CLEARDBSELECTIONCACHE() TROIA function removes all cached data, if TROIA programmers need to clear cache.

Varsayılan olarak, database selection cache etkindir, ama server configuration dosyasında (server settings dosyası) EnableDBSelectionCache ile bu seçeneği devre dışı bırakmak mümkündür. Database selection cache devre dışı bırakıldığında, TROIA interpreter WITHCACHE parametresini yok sayar ve tüm query'leri database'de gerçekleştirir.As default, database selection cache is enabled, but it is possible to disable this option with EnableDBSelectionCache on server configuration file (server settings file). When database selection cache disabled, TROIA interpreter ignores WITHCACHE parameter and performs all queries on database.