CN110851142A

CN110851142A - Method for converting Transact-SQL program into Java program

Info

Publication number: CN110851142A
Application number: CN201910994111.1A
Authority: CN
Inventors: 尹建伟; 智晨; 邓水光; 李莹
Original assignee: Zhejiang University ZJU
Current assignee: Zhejiang University ZJU
Priority date: 2019-10-18
Filing date: 2019-10-18
Publication date: 2020-02-28

Abstract

The invention discloses a method for converting a Transact-SQL (T-SQL) program into a Java program, which comprises the following steps: 1) acquiring a Transact-SQL object; 2) traversing the type definition codes to acquire global type information; 3) traversing the service logic code to obtain signature information and a dependency relationship; 4) determining a conversion sequence of the service logic codes; 5) and traversing the service logic codes in sequence, and executing a conversion process according to a conversion rule. On one hand, the program conversion method in the invention considers respective advantages of T-SQL and Java in the conversion process, not only retains the efficient operation of the T-SQL on the database, but also obtains the flexibility and expandability of the Java; on the other hand, by introducing an automatic conversion technology, the labor cost is reduced, and the conversion efficiency is improved.

Description

Method for converting Transact-SQL program into Java program

Technical Field

The invention belongs to the field of program conversion in computer software, and particularly relates to a method for converting a Transact-SQL program into a Java program.

Background

With the development of programming languages, new types of programming languages are being designed. Compared with the traditional programming language, the novel programming language often supports more high-level language characteristics, has stronger expression capability and quicker development and is more suitable for the technical development trend. Thus, many of the long-history business systems in the enterprise face the need to convert from traditional programming languages to new programming languages.

Sql (structured Query language), a structured Query language, is a standard language for relational databases and has been adopted by many database management systems. Transact-SQL (T-SQL for short) is an extension of Microsoft SQLSERVER to SQL, and provides procedural statements similar to C, Basic and Pascal, such as variables, control flows, subroutines and the like, so that SQL is not limited to standard database operation any more, becomes a powerful structured language, and can be used for completing business logic writing.

Java is an object-oriented programming language, not only absorbs various advantages of C + +, but also abandons concepts such as multiple inheritance, pointers and the like which are difficult to understand in C + +, so that the Java language has two characteristics of strong function, simplicity and easiness in use. Java, which allows programmers to perform complex programming in an elegant mental manner, is one of the mainstream programming languages at present and the first choice for writing enterprise applications.

Unlike the general program conversion scenario, T-SQL is a special programming language, which includes two parts, SQL statements and procedural statements, and the SQL statements must be executed by the database, so that the converted Java program has both Java code (usually converted from the procedural statements in T-SQL) and SQL statements (contained in Java JDBC API call statements and existing in Java strings). The two parts of codes run in different system software, Java codes run in a Java virtual machine, and SQL statements run in a database (when a Java program executes JDBC API call statements, SQL statements are transferred to the database through a system driver for execution). Such a mode of operation presents two major problems: (1) how the two codes perform data transfer at runtime; (2) how the SQL statement invokes the Java statement. The second problem is mainly caused by nesting some subprogram calls in the SQL statement, but the subprogram in T-SQL needs to be converted into a subprogram in Java as a whole, and the SQL statement cannot call the subprogram in Java when being executed in a database.

In addition, there are some special cases:

■ do not need to convert SQL statements into JDBC API call statements, but rather into native implementations in Java, because the syntax limitations of T-SQL itself result in some functions that can be easily accomplished in Java, and some complex SQL statements are needed in T-SQL.

■ some procedural statements must be executed by the database and thus require conversion of procedural statements into JDBC API calls the SET statement in T-SQL can usually be converted into an assignment statement in Java, but only into a JDBC API call if the database system state is changed by the SET statement.

In summary, converting T-SQL to Java is a very complex task. Moreover, a large amount of T-SQL codes are often accumulated in a real business system, and a large amount of time and labor are consumed for a developer to perform manual conversion.

Disclosure of Invention

In view of the above-mentioned drawbacks of the prior art, the present invention provides a method for converting a Transact-SQL program into a Java program.

In order to achieve the purpose, the invention adopts the following technical scheme:

a method of converting a Transact-SQL program into a Java program, comprising the steps of:

acquiring a Transact-SQL code;

traversing the type definition codes to acquire global type information;

traversing the service logic code to obtain signature information and a dependency relationship;

determining a conversion sequence of the service logic codes;

and traversing the service logic codes in sequence, and executing a conversion process according to a conversion rule.

In the above technical solution, the obtained Transact-SQL code further includes a database table definition code, a user definition type code, a function definition code, and a stored procedure definition code. The database table definition codes and the user definition type codes are collectively called type definition codes, and the types defined by the codes are global types which can be used by all business logic codes; the function definition code and the stored procedure definition code are collectively called business logic code, and executing the business code is a call to the function/stored procedure.

Further, the traversing the type definition code to obtain the global type information for subsequently converting the data type in the service logic code includes the following steps: firstly, constructing an abstract syntax tree AST of a T-SQL type definition code; then, traversing the abstract syntax tree, accessing specific node types, and extracting global type information which mainly comprises type names, subtype compositions and the like.

Further, traversing the service logic code, obtaining the signature information and the dependency relationship, and converting the sub-process call in the service logic code subsequently, including the following steps: firstly, constructing an abstract syntax tree of a T-SQL business logic code; then, traversing the abstract syntax tree, accessing a specific node type, and extracting signature information and dependency information;

the signature information comprises a name (function name/stored process name), information of input parameters and information of return values, and the number of the input parameters and the number of the return values are unlimited; the information of the input parameters comprises names, types, sequences and default values; the type of each input parameter or return value is any one specific type among a built-in type, a database table, and a custom type. The information of the return value includes name, type, order, etc.;

the dependency information is mainly embodied in the calling relationship between the service logic codes, and if the function/storage process A calls the function/storage process B, the function/storage process A is considered to depend on the function/storage process B.

Furthermore, the conversion sequence of the business logic codes mainly considers the dependency relationship between the codes, and the depended party needs to perform conversion before the depended party, so that the conversion sequence needs to be determined through topological sorting based on the dependency relationship.

Furthermore, after the conversion is completed, each T-SQL custom function/storage process is converted into an independent Java class, and an executable generation in the custom function/storage process is converted into a method body of a static method in the Java class.

Further, the actual conversion process comprises two parts of method signature generation and method body generation; the method signature is generated based on the T-SQL signature information extracted in the previous step and mainly comprises a method name, an input parameter type and a return value type; the method mainly comprises the following steps: constructing an abstract syntax tree based on the T-SQL business logic codes; traversing the T-SQL abstract syntax tree, and converting the T-SQL abstract syntax tree into a Java abstract syntax tree according to the conversion rule of the T-SQL abstract syntax tree and the type of the node adjacent to the node; and generating Java business logic codes according to the Java abstract syntax tree.

Further, in the process of generating a method body, special processing needs to be performed on a standard SQL statement containing a subroutine call to solve the problem of data transfer between Java code and SQL code, because the SQL statement needs to be executed in a database, and the subroutine call needs to be executed in a Java running environment; the conversion process of the SQL statement comprising the subprogram call mainly comprises three conditions, namely the calling of the subprogram built in the system, the calling of the self-defined subprogram independent of the SQL statement and the calling of the self-defined subprogram dependent on the SQL statement, wherein if the input parameter called by the subprogram refers to a data column of a database table, the execution result of the subprogram depends on the located SQL statement; the special treatment mainly comprises the following steps:

judging the type of the subprogram, if the subprogram is a system built-in subprogram, directly generating a JDBCAPI calling statement without converting the subprogram, because the SQL statement usually calls a large number of built-in subprograms, the conversion of the built-in subprograms causes great expansion of Java codes, and the built-in subprograms are relatively simple, and compared with the built-in subprograms, the conversion brings less benefit; if the sub-program is the self-defined sub-program, judging whether the execution result of the sub-program depends on the SQL statement, if the dependency does not exist, firstly, calling the self-defined sub-program is advanced, converting the calling of the self-defined sub-program into the sub-program calling statement in Java, storing a return value by using a local variable, then, changing the sub-program calling in the SQL statement into the reference of the return value, if the dependency exists, a uniform conversion scheme does not exist, and a developer needs to manually design the conversion scheme according to specific codes.

Further, the JDBC APIs are mainly classified into four categories, namely JDBC DECLARE API, JDBC SETAPI, JDBC EXECUTE APIs and JDBC GET APIs. JDBC DECLARE API is used for declaring SQL statements, JDBC SETAPI is used for initializing numerical values in the SQL statements, JDBC EXECUTE API is used for executing the SQL statements, and JDBC GET API is used for acquiring execution results of the SQL statements; the JDBC API call statement generation method comprises the following steps:

processing the SQL statement to obtain an SQL character string and generating a JDBC DECLARE API calling statement; judging whether the SQL statement quotes a variable, if so, acquiring corresponding Java variable information and generating a JDBC SET API calling statement; generating JDBC EXECUTE API calling statement; judging whether the SQL statement is a query statement, and if not, finishing the generation; if the query statement is the query statement, generating a JDBC GET API calling statement and generating an assignment statement;

the method for converting the subprogram calling statement in the Java comprises the following steps: if the optional parameters are used during calling, the optional parameters are supplemented according to the default values of the parameters declared during function definition; if the parameter name is used to specify the corresponding relation between the actual parameter and the form parameter during calling, generating the actual parameter list sequence according to the form parameter list sequence declared during function definition; and generating a Java subprogram calling statement.

Furthermore, the method for generating the JDBC GET API call statement and generating the assignment statement includes, for each return value of the JDBC EXECUTE API, performing the following steps:

firstly, acquiring type information, generating a variable statement to define a temporary variable, then generating an assignment statement, calling a corresponding JDBC GET API to acquire a return value, and storing the return value in the temporary variable;

the return value types are mainly divided into two types, namely a numerical value type and a database table type; for subprogram calls with a return value of a numerical value type, in the converted Java code, a temporary variable stores a real numerical value; for the subprogram call with the return value of the database table type, the temporary variable stores the table name in the converted Java code. For the subprogram call with the return value being in the database table type, the temporary variable stores the table name in the converted Java code, and when converting the subprograms, the temporary table for storing the return value is declared to be a globally unique formal table, and the table name of the formal table is returned. Because, for subroutines whose return values are of the database table type, they usually first create a temporary table inside the function body, then perform SQL operations on the temporary table, and finally return the temporary table. And the caller also performs SQL operations after getting the return value. It follows that operations on the temporary table all need to be completed in the database. To reduce data transfers, the present invention declares these temporary tables for storing return values as globally unique formal tables.

The invention has the beneficial effects that:

on one hand, the respective advantages of the T-SQL and the Java are considered in the conversion process, so that the efficient operation of the T-SQL on the database is reserved, and the flexibility and the expandability of the Java are obtained; on the other hand, by introducing an automatic conversion technology, the labor cost is reduced, and the conversion efficiency is improved.

Drawings

In order to more clearly describe the embodiments of the present invention, the drawings to be used in the embodiments will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the invention, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

FIG. 1 is a flowchart illustrating an overall program conversion method according to an embodiment of the present invention;

FIG. 2 is a conversion case for a single subroutine call provided by an embodiment of the present invention;

fig. 3 is a conversion case of a single SQL statement according to an embodiment of the present invention.

Detailed Description

The present invention will be further described in detail by some specific examples according to the program conversion method described in the present invention, but the present invention is not limited thereto.

Fig. 1 is a flowchart illustrating an overall program conversion method according to the present invention.

The T-SQL source code is obtained in the invention, and all T-SQL objects in the database instance can be exported by means of the existing tool, such as SQL Server Management Studio of Microsoft official database Management. Each T-SQL object is stored in a separate source code file, and the type of the SQL statement in the source code file can be judged by the suffix of the file name. For example, the file names of custom functions all end with userdefinidef function.

The method mainly acquires database table definition codes, type definition codes, function definition codes and storage process definition codes. The database table definition codes and the type definition codes are collectively called type definition codes, and the types defined by the codes are global types which can be used by all business logic codes; the function definition code and the stored procedure definition code are collectively called business logic code, and executing the business code is a call to the function/stored procedure.

The analysis of the T-SQL program in the invention is based on the common abstract syntax tree AST, so the AST is built and operated. In an embodiment of the present invention, an AST of T-SQL is created using ANTLR 4. ANTLR4 generates a lexical parser and a syntactic parser from a given syntactic description file, which parses the source code to obtain an abstract syntax tree AST.

Before entering the actual conversion process, some global information needs to be acquired to assist the subsequent conversion process.

Firstly, traversing the type definition code, and acquiring global type information for converting the data type in the service logic code subsequently. The process can be further divided into two sub-processes, first based on the parser generated by ANTLR4, and then constructing an abstract syntax tree AST of T-SQL type definition code. And traversing the abstract syntax tree, accessing specific node types, and extracting global type information which mainly comprises type names, subtype compositions and the like. For example, the name of a database Table may access a node fetch of type Table _ nameContext, and the composition of the database Table may access a node fetch of type Column _ definitionContext.

The following are the correspondence of some common T-SQL types, Java types and JDBC SET/GET APIs:

and traversing the service logic code to acquire signature information and the dependency relationship for converting the subprocess call in the service logic code subsequently. The process can be further divided into two sub-processes, and firstly, an abstract syntax tree of the T-SQL business logic code is constructed; the abstract syntax tree is then traversed, specific node types are accessed, and signature information and dependency information are extracted.

The signature information includes, among other things, a name (function name/stored procedure name), information of the input parameter, and information of the return value. The number of input parameters and the number of return values are not limited. The information of the input parameters includes name, type, order, default value, etc. The type of each input parameter or return value is any one specific type among a built-in type, a database table, and a custom type. The information of the return value includes name, type, order, etc. The dependency relationship is mainly embodied in the calling relationship between the service logic codes, and if the function/storage procedure a calls the function/storage procedure B, the function/storage procedure a is considered to depend on the function/storage procedure B.

Signature information of the custom function can be obtained by accessing a node of the Create _ or _ alter _ functional context type. The signature information of the self-defined storage process can be obtained by accessing the node of the Create _ or _ alter _ procedureContext type. The dependency relationship can be obtained by accessing the subprocess calling node, and the subprocess calling node in the T-SQL comprises a plurality of types, which are not listed one by one.

In practical systems, the source code is usually distributed in many different files, and the conversion sequence of the files needs to be determined. The conversion sequence mainly considers the dependency relationship between codes, and in principle, the depended party needs to convert before the depended party. The conversion order needs to be determined by topological sorting based on the dependency relationship.

Next, the actual conversion process is entered. And traversing the service logic codes in sequence according to the conversion sequence obtained in the previous step, and executing the conversion process according to the conversion rule. After the conversion is completed, each T-SQL self-defined function/storage process is converted into an independent Java class, and an executable generation in the self-defined function/storage process is converted into a static method in the Java class. As shown in FIG. 2, after the ReverseStr custom function in T-SQL is converted into Java code, the ReverseStr becomes a Java class, and the executable code is converted into a method body of execute method in the class.

The following are the transformation rules for a portion of the common T-SQL syntax:

in the invention, the generation of the Java program is based on the common abstract syntax tree AST, so the AST is built and manipulated. In an embodiment of the present invention, a Java AST is created using Eclipse JDT. Eclipse JDT may create an abstract syntax tree AST from scratch and may convert the AST into a source code output.

The actual conversion process mainly comprises two parts of method signature generation and method body generation. The method signature is generated based on the signature information extracted in the previous step, and mainly comprises a method name, an input parameter type and a return value type. The method mainly comprises the following steps: constructing an abstract syntax tree based on the T-SQL business logic codes; traversing the T-SQL abstract syntax tree, and converting the T-SQL abstract syntax tree into a Java abstract syntax tree according to the conversion rule of the T-SQL abstract syntax tree and the type of the node adjacent to the node; and generating Java business logic codes according to the Java abstract syntax tree.

In the process of generating the method body, special processing needs to be performed on the SQL statements including the subroutine calls to solve the problem of data transfer between Java code and SQL code. Here, the conversion process of the independent SQL statement is described first, then the conversion process called by the independent subroutine is described, and finally the conversion process of the SQL statement including the subroutine call is described.

The conversion process of the SQL statement without subprogram calling mainly comprises the following steps: processing the SQL statement to obtain an SQL character string and generating a JDBC DECLARE API calling statement; judging whether the SQL statement quotes a variable, if so, acquiring corresponding Java variable information and generating a JDBC SET API calling statement; generating JDBC EXECUTE API calling statement; judging whether the SQL statement is a query statement, and if not, finishing the generation; if the query statement is the query statement, a JDBC GET API call statement is generated and an assignment statement is generated. Specifically, for each return value of the JDBC EXECUTE API, a variable declaration statement is first generated to define a temporary variable, then an assignment statement is generated, and the corresponding JDBCGET API is called to obtain the return value and store it to the temporary variable. The return value types are largely classified into two types, a numeric type and a database table type. For subprogram calls with a return value of a numerical value type, in the converted Java code, a temporary variable stores a real numerical value; for the subprogram call with the return value being in the database table type, the temporary variable stores the table name in the converted Java code, and when converting the subprograms, the temporary table for storing the return value is declared to be a globally unique formal table, and the table name of the formal table is returned. Because, for subroutines whose return values are of the database table type, they usually first create a temporary table inside the function body, then perform SQL operations on the temporary table, and finally return the temporary table. And the caller also performs SQL operations after getting the return value. It follows that operations on the temporary table all need to be completed in the database. To reduce data transfers, the present invention declares these temporary tables for storing return values as globally unique formal tables.

As shown in FIG. 3, the Person in the data table contains two data columns, name and gender, and the SELECT statement takes out the corresponding gender according to the name. First, all JDBC APIs need to be placed in the try-catch code block to capture the exceptions that occur during database execution. The SELECT statement references an external variable name, so a JDBC SET API needs to be generated. The SELECT statement will return the gen der, so a JDBC GET API needs to be generated.

The conversion process of the independent subprogram call is explained, and the method mainly comprises the following steps: if the optional parameters are used during calling, the optional parameters are supplemented according to the default values of the parameters declared during function definition; if the parameter name is used to specify the corresponding relation between the actual parameter and the form parameter during calling, generating the actual parameter list sequence according to the form parameter list sequence declared during function definition; and generating a Java subprogram calling statement. In addition, many subprogram calls are calls to built-in subprograms, and the logic of the built-in subprograms is relatively simple, and the conversion of the built-in subprograms can be fixed as a conversion rule. The following are the transformation rules for some common T-SQL built-in subroutines:

T-SQL built-in subprogram	Java grammar
		cast	Java forced translation statement
charindex	String.indexof()
		isnull	Java ternary operator
len	Length, collection, size ()
		max	Math.max()
replace	String.replace()
		reverse	StringBuilder.reverse()
round	Math.round()
		substring	String.substring()
upper	String.toUpperCase()

As shown in fig. 2, the reverse built-in function is called by the reverse str custom function in T-SQL, and is replaced by the stringbuilder () syntax in Java.

The conversion process of the SQL statement containing the subprogram call mainly comprises three conditions, namely the subprogram call built in the system, the self-defined subprogram call independent of the SQL statement and the self-defined subprogram call dependent on the SQL statement. If the input parameters called by the number of the subprograms refer to some data columns of some database tables, the execution result of the subprograms depends on the SQL statements. The conversion process mainly comprises the following steps: judging the type of the subprogram, if the subprogram is a system built-in subprogram, directly generating a JDBC API calling statement without converting the subprogram, because the SQL statement usually calls a large number of built-in subprograms, the conversion of the built-in subprograms causes great expansion of Java codes, and the built-in subprograms are relatively simple, and the conversion brings less benefit; if the sub-program is the self-defined sub-program, judging whether the execution result of the sub-program depends on the SQL statement, if the dependency does not exist, firstly, calling the self-defined sub-program is advanced, converting the calling of the self-defined sub-program into the sub-program calling statement in Java, storing a return value by using a local variable, then, changing the sub-program calling in the SQL statement into the reference of the return value, if the dependency exists, a uniform conversion scheme does not exist, and a developer needs to manually design the conversion scheme according to specific codes.

Taking a large-scale internet company as an example, a core ERP system of the large-scale internet company is initially developed by using a T-SQL language, as shown in table 1, the company adopting the automatic conversion technology of the present invention can greatly reduce the labor cost and improve the conversion efficiency. Due to the fact that the system scale is continuously enlarged in recent years, the defects that the T-SQL language is not easy to reuse and expand are more and more prominent, and therefore managers plan migration to migrate the whole system to the Java language. The results of the conversion method of the present invention are shown in the following table, which can greatly reduce the manpower input.

TABLE 1 statistics of transcoding situations performed by a company using the method of the present invention

Total number of code lines	Automatically converting the number of code lines	Requiring manual translation of the number of code lines
			906208	879643	26565
100％	97.1％	2.9％

Claims

1. A method for converting a Transact-SQL program into a Java program, comprising the steps of:

acquiring a Transact-SQL code;

traversing the type definition codes to acquire global type information;

determining a conversion sequence of the service logic codes;

2. The method for converting Transact-SQL program into Java program according to claim 1, wherein the obtained Transact-SQL code comprises database table definition code, user defined type code, function definition code, stored procedure definition code.

3. The method for converting Transact-SQL procedure into Java program according to claim 1, wherein traversing the type definition code, obtaining the global type information, comprises the following steps:

constructing an abstract syntax tree AST of the T-SQL type definition code;

and traversing the abstract syntax tree, accessing the specific node type, and extracting the global type information.

4. The method for converting Transact-SQL procedure into Java program according to claim 1, wherein traversing the service logic code, obtaining signature information and dependencies, comprises the following steps:

constructing an abstract syntax tree of the T-SQL business logic code;

traversing the abstract syntax tree, accessing a specific node type, and extracting signature information and dependency information;

the signature information comprises a function name/storage process name, information of input parameters and information of return values, and the number of the input parameters and the number of the return values are not limited; the information of the input parameters comprises names, types, sequences and default values; the information of the return value comprises a name, a type and a sequence; the type of each input parameter or return value is any specific type of a built-in type, a database table and a custom type;

the dependency information is mainly embodied in the calling relationship between the business logic codes.

5. The method according to claim 4, wherein the conversion order of the business logic code mainly considers the dependency relationship, the depended party is to perform conversion before the depended party, and the conversion order is determined by topological sorting based on the dependency relationship.

6. The method of converting Transact-SQL procedures into Java programs according to claim 5, wherein after the conversion is completed, each T-SQL custom function/stored procedure is converted into an independent Java class, and executable code in the custom function/stored procedure is converted into a method body of a static method in the Java class.

7. The method for converting a Transact-SQL program into a Java program according to claim 4, wherein the conversion process includes two parts, a method signature generation part and a method body generation part, the method signature is generated based on the extracted signature information, and includes a method name, an input parameter type and a return value type; the method for generating the method body comprises the following steps:

constructing an abstract syntax tree based on the T-SQL business logic codes;

traversing the T-SQL abstract syntax tree, and converting the T-SQL abstract syntax tree into a Java abstract syntax tree according to the conversion rule of the T-SQL abstract syntax tree and the type of the node adjacent to the node;

and generating Java business logic codes according to the Java abstract syntax tree.

8. The method for converting Transact-SQL procedure into Java program according to claim 7, wherein in the process of generating the method body, special processing needs to be performed on the standard SQL statement that includes the subroutine call to solve the data transmission problem between Java code and SQL code; the special treatment comprises the following steps:

judging the type of the subprogram, and if the subprogram is a system built-in subprogram, directly generating a JDBC API calling statement without converting the subprogram; if the subprogram is the self-defined subprogram, judging whether the execution result of the subprogram depends on the SQL sentence, if the execution result of the subprogram does not depend on the SQL sentence, firstly, calling the self-defined subprogram is advanced, the self-defined subprogram is converted into the subprogram calling sentence in Java, a local variable is used for storing a return value, then, calling the subprogram in the SQL sentence is changed into reference of the return value, if the execution result of the subprogram is dependent on the Java subprogram, a uniform conversion scheme does not exist, and a developer needs to manually design the conversion scheme according to specific codes;

for a self-defined subroutine, if the input parameters called by the subroutine reference a data column of a database table, then the result of the execution of the subroutine depends on the underlying SQL statement.

9. The method according to claim 8, wherein the JDBC APIs are divided into four classes, which are JDBC DECLARE API, JDBC SET API, JDBC EXECUTE API and JDBC GET API, the JDBC DECLARE API is used for declaring SQL statements, the JDBC SET API is used for initializing values in SQL statements, the JDBC EXECUTE API is used for executing SQL statements, and the JDBC GET API is used for obtaining execution results of SQL statements; the JDBC API call statement generation method comprises the following steps:

processing the SQL statement to obtain an SQL character string and generating a JDBC DECLARE API calling statement;

judging whether the SQL statement quotes a variable, if so, acquiring corresponding Java variable information and generating a JDBC SET API calling statement;

generating JDBC EXECUTE API calling statement;

judging whether the SQL statement is a query statement, and if not, finishing the generation; if the query statement is the query statement, generating a JDBC GET API calling statement and generating an assignment statement;

the conversion into the subprogram calling statement in Java comprises the following steps:

if the optional parameters are used during calling, the optional parameters are supplemented according to the default values of the parameters declared during function definition;

if the parameter name is used to specify the corresponding relation between the actual parameter and the form parameter during calling, generating the actual parameter list sequence according to the form parameter list sequence declared during function definition;

and generating a Java subprogram calling statement.

10. The method of converting a Transact-SQL program into a Java program according to claim 9, wherein the method of generating JDBC GET API call statements and generating assignment statements is such that for each return value of JDBC EXECUTE API the following steps are performed:

acquiring type information;

generating variable statement statements and declaring temporary variables;

generating an assignment statement, calling a corresponding JDBC GET API to obtain a return value, and storing the return value in a temporary variable; the returned value is called by a subprogram with the value type, and in the converted Java code, the temporary variable is stored with a real value; for the subprogram call with the return value being in the database table type, the temporary variable stores the table name in the converted Java code, and when converting the subprograms, the temporary table for storing the return value is declared to be a globally unique formal table, and the table name of the formal table is returned.