Oracle compatible method and device based on database driver

Abstract

The embodiment of the present application discloses an Oracle-compatible method and device based on a database driver, which belongs to the field of database migration technology. It solves the problem that the existing technology is difficult to achieve full compatibility with Oracle features at the driver level. It includes receiving Oracle-style call statements at the driver layer when the database is in Oracle-compatible mode; determining the corresponding syntax conversion strategy according to the type of call statement in the stage of generating and executing SQL statements; performing syntax conversion on the call statement based on the syntax conversion strategy to obtain statements supported by the target database kernel and send them to the target database kernel; parsing the result set returned by the target database kernel in the stage of obtaining the result set, passing the parsed function return value and / or out parameter value to the corresponding binding variable to achieve compatibility with Oracle functions, stored procedures and anonymous blocks.

Description

Technical Field

[0001] The present application relates to the technical field of database migration, and in particular to an Oracle-compatible method and device based on a database driver. Background Art

[0002] With the advancement of enterprise digital transformation, the demand for database migration is increasing. Among them, the migration scenario from Oracle database to PostgreSQL-derived database is particularly common.

[0003] However, Oracle and PostgreSQL differ significantly in the syntax implementation of key features such as stored procedures, functions, and anonymous blocks. Similarly, there are significant differences in the implementation of the Oracle ODBC driver and the PostgreSQL ODBC driver, each parsing the application's execution commands into syntax recognized by the corresponding database. As the target database, PostgreSQL-derived databases implement compatibility with Oracle-related features at the kernel level. If the driver does not perform compatible modifications to the corresponding Oracle syntax parsing, the target database kernel will have difficulty recognizing the parsed syntax. In this case, the application will require extensive code modifications to achieve compatibility with the target database. Furthermore, due to the lack of support for functions, stored procedures, and anonymous blocks, business logic must be rewritten after migration, compromising code consistency.

[0004] Existing technologies primarily rely on manual code refactoring to address Oracle and PostgreSQL compatibility issues, but this approach is inefficient and difficult to implement for large-scale code migrations. While some database drivers currently offer Oracle feature compatibility, these drivers are often designed for specific databases and offer limited support for Oracle features, making full Oracle feature compatibility difficult to achieve at the driver level. Summary of the Invention

[0005] The embodiments of the present application provide an Oracle-compatible method and device based on a database driver, which is used to solve the following technical problem: although the existing database drivers are compatible with Oracle features, their database drivers are mostly designed for specific databases and have limited support for Oracle features. It is still difficult to achieve full compatibility with Oracle features at the driver level.

[0006] The embodiments of this application adopt the following technical solutions:

[0007] The present invention provides an Oracle-compatible method based on a database driver. The method comprises: receiving a call statement in Oracle format at the driver layer when the database is in Oracle-compatible mode; determining a corresponding syntax conversion strategy based on the type of the call statement during the SQL statement generation and execution phase; wherein the call statement includes a function call statement, a stored procedure call statement, and an anonymous block call statement; performing syntax conversion on the call statement based on the syntax conversion strategy to obtain a statement supported by the target database kernel, and sending the statement to the target database kernel; and parsing the result set returned by the target database kernel during the result set acquisition phase, passing the parsed function return value and / or out parameter value to the corresponding bind variable to achieve compatibility with Oracle functions, stored procedures, and anonymous blocks.

[0008] The embodiment of the present application automatically identifies Oracle-style call statements through the driver layer and converts them into syntax supported by the target database kernel. It can be run directly without modifying the native Oracle syntax code, reducing the workload of migration. Secondly, in view of key differences such as the return value position of Oracle functions, out parameter passing of stored procedures, and anonymous block pattern recognition, the driver layer automatically adjusts the parameter order through configuration parameters and performs bitwise operations on variable type identifiers to ensure that the target database kernel accurately recognizes function prototypes and parameter patterns, avoiding execution errors caused by type mismatches in traditional drivers. Developers do not need to learn PostgreSQL syntax separately, which reduces learning costs, reduces adaptation issues, and shortens the migration cycle.

[0009] In one implementation of the present application, based on a syntax conversion strategy, a syntax conversion is performed on a calling statement to obtain a statement supported by the target database kernel, specifically including: when the calling statement is a function call statement, adjusting the configuration parameters of the target database kernel according to the parameter placeholder information corresponding to the function call statement to determine the placement position of the function return value; using the function return value as an output parameter and recombining it with the input parameters into a parameter placement sequence supported by the target database; based on the parameter placement sequence, converting the function call statement into a SELECT statement form to obtain a statement supported by the target database kernel corresponding to the function call statement.

[0010] In one implementation of the present application, the configuration parameters of the target database kernel are adjusted according to the parameter placeholder information corresponding to the function call statement to determine the placement position of the function return value, specifically including: according to the type and form of the parameter placeholder corresponding to the function call statement; based on the type and form, the configuration parameter result_first of the target database kernel is adjusted to true to place the function return value as the out parameter at the first position of the parameter; or, the configuration parameter result_first of the target database kernel is adjusted to false to place the function return value as the out parameter at the last position of the parameter.

[0011] In one implementation of the present application, before obtaining the statement supported by the target database kernel corresponding to the function call statement, the method further includes: binding a type identifier for each parameter; wherein the type identifier of the output parameter is consistent with the type identifier of the function return value.

[0012] In one implementation of the present application, based on a syntax conversion strategy, a syntax conversion is performed on a calling statement to obtain a statement supported by the kernel of a target database, specifically including: when the calling statement is a stored procedure calling statement, based on the composition characteristics of the stored procedure calling statement, it is divided into statements that do not need to be converted and statements that need to be converted; wherein the composition characteristics of the statement include specific brackets and parameter placeholder information; based on the syntax conversion strategies corresponding to the statements that do not need to be converted and the statements that need to be converted, the calling statement is syntax converted to obtain a statement supported by the kernel of the target database.

[0013] In one implementation of the present application, based on the syntax conversion strategies corresponding to statements that do not require conversion and statements that require conversion, the calling statement is subjected to syntax conversion, specifically including: in the case of statements that do not require conversion, the original syntax structure of the stored procedure calling statement remains unchanged; in the case of statements that require conversion, the specific brackets of the stored procedure calling statement are adjusted to keep the parameter placement sequence and bound variables within the specific brackets unchanged.

[0014] In one implementation of the present application, based on a syntax conversion strategy, a syntax conversion is performed on a calling statement to obtain a statement supported by the target database kernel, specifically including: when the calling statement is an anonymous block calling statement, a preset keyword detection is performed on the SQL statement to determine the real anonymous block; based on the real anonymous block, the corresponding SQL statement is converted into a do+using syntax; wherein the do+using syntax includes a code block and a parameter pattern; according to the input and output mode of the parameter, a bit operation is performed on the variable type identifier to achieve mode distinction; wherein the parameter pattern corresponds to the number of variables and the variable pattern, so that the output parameters in the real anonymous block are transmitted.

[0015] In one implementation of the present application, bit operations are performed on the variable type identifier to achieve mode distinction, specifically including: adding a variable type identifier to the parameter information structure; performing bit operations on the variable type identifier with different hexadecimals to distinguish the modes; wherein the modes include in mode, out mode and inout mode.

[0016] In one implementation of the present application, the parsed function return value and / or out parameter value is passed to the corresponding bind variable, specifically including: when executing a function call statement or a stored procedure call statement, the return value and out parameter value are obtained by parsing the record returned by the target database kernel, and the return value and out parameter value are passed to the corresponding bind variable; when executing an anonymous block call statement, the out parameter value is obtained by parsing the record returned by the target database kernel, and the out parameter value is passed to the corresponding bind variable.

[0017] An embodiment of the present application provides an Oracle-compatible device based on a database driver, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so as to enable the at least one processor to: receive a call statement in Oracle format at a driver layer when the database is in Oracle-compatible mode; determine a corresponding syntax conversion strategy according to the type of the call statement during the generation and execution of SQL statements; wherein the call statement includes a function call statement, a stored procedure call statement, and an anonymous block call statement; based on the syntax conversion strategy, perform syntax conversion on the call statement to obtain a statement supported by the target database kernel, and send the statement to the target database kernel; during the result set acquisition stage, parse the result set returned by the target database kernel, and pass the parsed function return value and / or out parameter value to the corresponding bind variable to achieve compatibility with Oracle functions, stored procedures, and anonymous blocks.

[0018] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: The embodiments of the present application automatically identify Oracle-style call statements through the driver layer and convert them into syntax supported by the target database kernel. They can be run directly without modifying the native Oracle syntax code, reducing the workload of migration. Secondly, in response to key differences such as the return value position of Oracle functions, out parameter passing of stored procedures, and anonymous block pattern recognition, the driver layer automatically adjusts the parameter order through configuration parameters and performs bitwise operations on variable type identifiers to ensure that the target database kernel accurately recognizes function prototypes and parameter patterns, avoiding execution errors caused by type mismatches in traditional drivers. Developers do not need to learn PostgreSQL syntax separately, which reduces learning costs, reduces adaptation issues, and shortens the migration cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments described in the present application. For those skilled in the art, other drawings can be obtained based on these drawings without inventive work. In the drawings:

[0020] Figure 1 A driver layer processing flow chart provided in an embodiment of the present application;

[0021] Figure 2 A flowchart of an Oracle-compatible method based on a database driver provided in an embodiment of the present application;

[0022] Figure 3 A schematic diagram of the structure of an Oracle-compatible device based on a database driver provided in an embodiment of the present application.

[0023] Reference numerals:

[0024] 200: Oracle-compatible device based on database driver, 201: processor, 202: memory. DETAILED DESCRIPTION

[0025] The embodiments of the present application provide an Oracle-compatible method and device based on a database driver.

[0026] In order to enable those skilled in the art to better understand the technical solutions in this application, the following will clearly and completely describe the technical solutions in the embodiments of this application in conjunction with the drawings in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0027] The technical solutions proposed in the embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0028] The Open Database Connectivity (ODBC) interface is a C programming language interface that enables applications to access data from various database management systems (DBMS). The ODBC architecture has four main components:

[0029] Application: Performs processing and calls ODBC functions to submit SQL statements and retrieve results.

[0030] Driver Manager: Loads and unloads drivers on behalf of applications and handles ODBC function calls or passes them to drivers.

[0031] Driver: Processes ODBC function calls, submits SQL requests to a specific data source, and returns results to the application.

[0032] Data source: The specific data that the user wants to access and its associated operating system.

[0033] The psqlODBC driver belongs to the "driver" component in the ODBC architecture and is a driver specific to the Postgresql database. The embodiment of the present application performs syntax and functional compatibility modification on Oracle functions, stored procedures, and anonymous blocks based on the psqlODBC driver. Figure 1 A driver layer processing flow chart provided in an embodiment of the present application is as follows: Figure 1 As shown in the figure, the basic processing flow of the driver layer includes:

[0034] Connect to the data source: allocate an environment handle and a connection handle, and connect to the target database in Oracle-compatible mode;

[0035] Initialize the application: allocate statement handles, set statement attributes, etc.;

[0036] Generate and execute SQL statements: After generating the SQL statement and binding any parameters, execute the statement directly, or prepare the statement first and then execute it;

[0037] Get result set: If it is a query statement or catalog function, retrieve data row by row. If it is a CRUD statement, get the number of affected rows.

[0038] Commit transaction: When the transaction commit mode is set to manual commit, execute the commit transaction;

[0039] Disconnect from the data source: release the statement handle, disconnect the database link, and release the connection handle and environment handle.

[0040] Among them, the driver layer in the embodiment of the present application mainly transforms the compatible functions and syntax of Oracle functions, stored procedures and anonymous blocks in the "generating and executing SQL statements" and "obtaining result sets" parts.

[0041] Figure 2 A flowchart of an Oracle compatible method based on a database driver is provided in an embodiment of the present application, such as Figure 2 As shown, the Oracle-compatible method based on the database driver includes the following steps:

[0042] Step 101: When the database is in Oracle compatible mode, a call statement in Oracle format is received at the driver layer.

[0043] In one implementation of this application, by setting database parameters, the driver enables Oracle compatibility mode, triggering special processing logic for Oracle syntax. In this mode, the driver will actively identify and convert Oracle-specific call statements.

[0044] Step 102: During the SQL statement generation and execution phase, a corresponding syntax conversion strategy is determined according to the type of the calling statement.

[0045] In one implementation of the present application, the driver classifies call statements into three categories by analyzing the structural characteristics of the statements: function call statements, stored procedure call statements, and anonymous block call statements.

[0046] Function call statement: The characteristic is that it contains return value binding, such as {? = call function} or call ...into structure, which is used to execute a function with a return value.

[0047] Stored procedure call statement: starts with the call keyword and can be enclosed in curly braces, such as {call procedure}, which is used to execute a stored procedure without a return value.

[0048] Anonymous block call statement: starts with BEGIN and ends with END, contains variable declarations and complex logic, and is used to execute a complete PL / SQL code block.

[0049] The driver determines the appropriate syntax conversion strategy based on the type of call statement. This allows for high compatibility with Oracle PL / SQL syntax without or with minimal application modifications, reducing the technical barriers and costs of database migration.

[0050] Step 103: Based on the syntax conversion strategy, perform syntax conversion on the call statement to obtain a statement supported by the target database kernel, and send the statement to the target database kernel.

[0051] In one implementation of the present application, when the call statement is a function call statement, the configuration parameters of the target database kernel are adjusted based on the parameter placeholder information corresponding to the function call statement to determine the placement of the function return value. The function return value is used as an output parameter and recombined with the input parameters to form a parameter placement sequence supported by the target database. Based on the parameter placement sequence, the function call statement is converted into a SELECT statement to obtain a statement supported by the target database kernel corresponding to the function call statement.

[0052] Specifically, if the call statement is a function call, the driver must dynamically adjust the database configuration based on the parameter placeholder information, reorder the parameters, and convert it into a SELECT statement supported by the target database. Specifically, the driver determines the type and form of the parameter placeholders corresponding to the function call statement. Based on the type and form, the target database kernel configuration parameter "result_first" is set to "true" to place the function return value as the first out parameter. Alternatively, the driver can set the target database kernel configuration parameter "result_first" to "false" to place the function return value as the last out parameter.

[0053] The following is an example of converting the syntax of a function call statement. It should be noted that the names of the following functions and stored procedures are replaced by "function" and "procedure". In actual application, the specific defined function and stored procedure names are used, and the number of parameters is not fixed, which can be one, multiple, or no parameters:

[0054] (1) For function calls in the question mark placeholder format { ? = call function(?, ?, ?)}, the driver converts it into a SELECT statement and places the function return value first as the out parameter. The database kernel has a configuration parameter called result_first, which defaults to true, meaning the return value is placed first. This is equivalent to the four-parameter function in the example above being converted into a SELECT statement in the form of SELECT * FROM function(?, ?, ?, ?), where the first question mark is the return value. The parameter type identifier id is the same as the parameter type identifier id of the out parameter. The driver sends this statement to the database kernel, which can then identify the function prototype based on the parameter type.

[0055] (2) For the function call in the form of colon-bound variables {:ret = call function(:1,:2,:3)}, the driver adds the recognition of colon placeholder variables and converts it into the SELECT statement form of SELECT * FROM function(:ret, :1, :2, :3).

[0056] Specifically, the {:ret = call ...} structure identifies :ret as the bind variable for the function's return value. The colon variable in the parameter list is extracted and used as a placeholder for the input parameter. The driver adjusts the database kernel parameter result_first=true, indicating that the return value should be placed first in the parameter list. The driver converts the colon-bound call in Oracle into a SELECT statement supported by the target database. The colon variables are arranged in the order [return value, input parameter 1, input parameter 2, ...] to ensure consistency with Oracle call semantics. Type information is bound to each colon variable, ensuring that the type of the return value :ret matches the return type defined in the function and that the types of the input parameters correspond to the parameter types defined in the function.

[0057] Furthermore, when the converted SELECT statement is passed to the target database kernel, the kernel checks whether the total number of parameters is consistent with the function definition. Through the type identifier of the colon variable, the kernel verifies whether the parameter type matches the function prototype. After executing the function, the kernel passes the return value to the driver through the :ret variable, which is then mapped to the application's bind variable.

[0058] (3) For a function call in the form of call function(?, ?, ?) into ?, the driver converts it into a SELECT statement and places the function return value as the out parameter at the end of the parameter (and sets the configuration parameter result_first to false, that is, the return value is placed at the end). The SELECT statement is converted into SELECT * FROMfunction(?, ?, ?, ?), where the last question mark is the return value and is sent to the database kernel. The kernel can identify the function prototype based on the parameter type.

[0059] Specifically, the driver uses the call ... into ? structure to identify the last question mark as a placeholder for the function's return value. The question mark placeholder between call and into is extracted and identified as the function's input parameter. The total number of input parameter and return value placeholders is counted. For example, call func(?, ?, ?) into ? involves four parameters. The driver controls the position of the return value by adjusting the database kernel's result_first parameter. Specifically, by setting result_first to false, the return value is placed last in the parameter list. The input parameters are arranged in their original order, with the return value as the last parameter, forming a parameter sequence of [input parameter 1, input parameter 2, ..., return value]. The driver converts the corresponding Oracle function call into a SELECT statement supported by the target database. Type information is bound to each question mark placeholder to ensure that the return value's type identifier is consistent with the function's return type and that the input parameter type identifiers match the function's parameter types in order.

[0060] In one implementation of the present application, when a call statement is a stored procedure call statement, the call statement is classified into statements that do not require conversion and statements that do require conversion based on the compositional features of the stored procedure call statement, wherein the compositional features of the statement include specific brackets and parameter placeholder information. Based on the syntax conversion strategies corresponding to the statements that do not require conversion and those that do require conversion, the call statement is syntactically converted to obtain a statement supported by the target database kernel.

[0061] Specifically, if the statement does not require conversion, the original grammatical structure of the stored procedure call statement is maintained. If the statement requires conversion, the specific brackets of the stored procedure call statement are adjusted, and the parameter placement sequence and bind variables within the specific brackets are maintained unchanged.

[0062] Specifically, the following is an example of syntax conversion for a stored procedure call statement:

[0063] For the standard ODBC stored procedure call format of { call procedure(?, ?, ?)}, the driver removes the curly braces, leaving the contents within unchanged and sending them to the database kernel, which recognizes the stored procedure's CALL syntax. For the colon-bound variable format of call procedure(:1, :2), the driver does not perform any conversion and sends the call to the database kernel as is, which recognizes the stored procedure's CALL syntax.

[0064] In one implementation of the present application, when a call statement is an anonymous block call statement, a preset keyword check is performed on the SQL statement to identify a true anonymous block. Based on the true anonymous block, the corresponding SQL statement is converted into a do+using syntax; the do+using syntax includes a code block and a parameter pattern. Based on the input and output modes of the parameters, a bitwise operation is performed on the variable type identifier to achieve mode differentiation. The parameter pattern corresponds to the number of variables and the variable pattern, so that the output parameters in the true anonymous block are transmitted.

[0065] Specifically, for all Oracle call forms of anonymous blocks, we first need to determine whether the SQL statement is a true anonymous block call or a normal transaction block. Specifically, we treat the entire SQL statement as a string, skipping the leading comment and whitespace characters, and then perform the following judgment on the remaining string:

[0066] 1. Starting with "DECLARE", it can be determined to be an anonymous block;

[0067] 2. If it starts with "BEGIN" and has a matching "END", and the statement contains the transaction control statement "COMMIT" or "ROLLBACK", it is a transaction block; otherwise, it is an anonymous block.

[0068] Furthermore, after determining that it is an anonymous block, the SQL statement is converted to do+using syntax, and the variables of the anonymous block need to be bitwise ORed with different hexadecimals according to different modes to distinguish different modes. That is, the anonymous block in Oracle syntax is converted to do+using syntax, the data type of the parameter is added to the parameter information structure, and bitwise ORed with different hexadecimals so that the database kernel can distinguish the in / out / inout mode of the parameter. This syntax allows the out variable contained in the anonymous block to be transmitted. Step 104, in the result set acquisition stage, parse the result set returned by the target database kernel, and pass the parsed function return value and / or out parameter value to the corresponding bind variable to achieve compatibility with Oracle functions, stored procedures and anonymous blocks.

[0069] In one implementation of the present application, when executing a function call statement or a stored procedure call statement, the record returned by the target database kernel is parsed to obtain the return value and out parameter value, and the return value and out parameter value are passed to the corresponding bind variable. When executing an anonymous block call statement, the record returned by the target database kernel is parsed to obtain the out parameter value, and the out parameter value is passed to the corresponding bind variable.

[0070] Specifically, for Oracle function and stored procedure calls, the Result Set Acquisition section adds support for obtaining result sets. In the result set, the kernel combines the function return value and other out parameters into a record. The driver parses the record and passes the return value and out parameter values ​​to the corresponding bind variables. For Oracle anonymous block calls containing out parameters, the kernel combines all out parameters into a record. The driver parses the record and passes the out parameter values ​​to the corresponding bind variables.

[0071] In the embodiment of the present application, the psqlODBC driver receives Oracle's corresponding functions, stored procedures, and anonymous blocks, converts the syntax into syntax supported by the database kernel in the "Generate and Execute SQL Statements" section, and passes the return value and out parameters (if any) to the corresponding bind variables in the "Get Result Set" section, thereby achieving compatibility with Oracle functions, stored procedures, and anonymous blocks.

[0072] There are differences between traditional Oracle's PL / SQL syntax and PostgreSQL's PL / pgSQL, resulting in a large amount of code rewriting required for migration. The embodiment of the present application automatically converts at the driver layer, reducing the amount of modification to the client application, or even eliminating the need for modification, thereby reducing development costs. Secondly, the embodiment of the present application adapts Oracle syntax logic at the driver layer, and the application can directly execute Oracle-style functions, stored procedures, and anonymous blocks. The embodiment of the present application eliminates the need for developers to learn PostgreSQL syntax separately, reducing learning costs. It reduces adaptation issues and shortens the migration cycle.

[0073] Figure 3 This is a schematic diagram of the structure of an Oracle compatible device based on a database driver provided in an embodiment of the present application. Figure 3As shown, an Oracle-compatible device 200 based on a database driver includes: at least one processor 201; and a memory 202 communicatively connected to the at least one processor 201; wherein the memory 202 stores instructions that can be executed by the at least one processor 201, and the instructions are executed by the at least one processor 201 so that the at least one processor 201 can: when the database is in Oracle-compatible mode, receive Oracle-formatted call statements at the driver layer; in the stage of generating and executing SQL statements, determine a corresponding syntax conversion strategy according to the type of the call statement; wherein the call statement includes a function call statement, a stored procedure call statement, and an anonymous block call statement; based on the syntax conversion strategy, perform syntax conversion on the call statement to obtain a statement supported by the target database kernel, and send it to the target database kernel; in the stage of obtaining a result set, parse the result set returned by the target database kernel, and pass the parsed function return value and / or out parameter value to the corresponding bind variable to achieve compatibility with Oracle functions, stored procedures, and anonymous blocks.

[0074] The various embodiments in this application are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the device, apparatus, and non-volatile computer storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simple. For relevant portions, refer to the descriptions of the method embodiments.

[0075] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. It will be apparent to those skilled in the art that various modifications and variations may be made to the embodiments of the present application. However, such modifications or substitutions do not deviate from the spirit and scope of the technical solutions of the various embodiments of the present application.

Claims

1. An Oracle compatible method based on a database driver, characterized in that: The method comprises: When the database is in Oracle compatibility mode, the driver layer receives Oracle-style call statements; During the SQL statement generation and execution phase, a corresponding syntax conversion strategy is determined according to the type of the call statement; wherein the call statement includes a function call statement, a stored procedure call statement, and an anonymous block call statement; Based on the syntax conversion strategy, the calling statement is syntax-converted to obtain a statement supported by the target database kernel and sent to the target database kernel; in the result set acquisition phase, the result set returned by the target database kernel is parsed, and the parsed function return value and / or out parameter value is passed to the corresponding bind variable to achieve compatibility with Oracle functions, stored procedures, and anonymous blocks; The step of performing syntax conversion on the call statement based on the syntax conversion strategy to obtain a statement supported by the target database kernel specifically includes: In a case where the calling statement is the function calling statement, adjusting the configuration parameters of the target database kernel according to the parameter placeholder information corresponding to the function calling statement to determine the placement position of the function return value; The function return value is used as an output parameter and recombined with the input parameters into a parameter placement sequence supported by the target database; Based on the parameter placement sequence, convert the function call statement into a SELECT statement form to obtain a statement supported by the target database kernel corresponding to the function call statement; The step of adjusting the configuration parameters of the target database kernel according to the parameter placeholder information corresponding to the function call statement to determine the placement position of the function return value specifically includes: Determine the type and form of the parameter placeholder corresponding to the function call statement; Based on the type and form, adjust the configuration parameter result_first of the target database kernel to true to place the function return value as the out parameter first; Alternatively, the configuration parameter result_first of the target database kernel is adjusted to false, so that the function return value is placed at the end of the parameters as an out parameter; Before obtaining the statement supported by the target database kernel corresponding to the function call statement, the method further includes: Bind a type identifier to each parameter; Wherein, the type identifier of the output parameter is consistent with the type identifier of the function return value; The step of performing syntax conversion on the call statement based on the syntax conversion strategy to obtain a statement supported by the target database kernel specifically includes: In the case where the calling statement is the anonymous block calling statement, performing preset keyword detection on the SQL statement to determine the real anonymous block; Based on the real anonymous block, the corresponding SQL statement is converted into a do+using syntax; wherein the do+using syntax includes a code block and a parameter pattern; according to the input and output modes of the parameters, a bitwise operation is performed on the variable type identifier to achieve mode differentiation; wherein the parameter pattern corresponds to the number of variables and the variable pattern, so that the output parameters in the real anonymous block are transmitted; The bitwise operation processing of the variable type identifier to achieve mode differentiation specifically includes: Add variable type identifier in the parameter information structure; Perform bitwise calculations on the variable type identifier and different hexadecimal systems to distinguish modes; wherein the modes include in mode, out mode, and inout mode; The method of passing the parsed function return value and / or out parameter value to the corresponding binding variable specifically includes: When executing the function call statement or the stored procedure call statement, the record returned by the target database kernel is parsed to obtain a return value and an out parameter value, and the return value and the out parameter value are passed to corresponding bind variables; When the anonymous block call statement is executed, the record returned by the target database kernel is parsed to obtain the out parameter value, and the out parameter value is passed to the corresponding binding variable.

2. The Oracle-compatible method based on a database driver according to claim 1, characterized in that: The step of performing syntax conversion on the call statement based on the syntax conversion strategy to obtain a statement supported by the target database kernel specifically includes: In the case where the calling statement is the stored procedure calling statement, the calling statement is divided into a statement that does not require conversion and a statement that requires conversion based on the constituent features of the stored procedure calling statement; wherein the constituent features of the statement include specific brackets and parameter placeholder information; Based on the syntax conversion strategies corresponding to the statements that do not need to be converted and the statements that need to be converted, the calling statements are syntax converted to obtain statements supported by the target database kernel.

3. The Oracle compatible method based on a database driver according to claim 2, characterized in that: The syntax conversion of the call statement based on the syntax conversion strategies corresponding to the statements that do not need to be converted and the statements that need to be converted, specifically includes: In the case of the statement that does not require conversion, the original grammatical structure of the stored procedure call statement is kept unchanged; In the case of the statement that needs to be converted, the specific brackets of the stored procedure call statement are adjusted, and the parameter placement sequence and bound variables in the specific brackets are kept unchanged.

4. An Oracle-compatible device based on a database driver, characterized in that: The device comprises a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to execute the method according to any one of claims 1 to 3.

Images