| Note: Built-In Function Rules Usage Options |
Disconnects the current function from a previously connected server.
A request to disconnect a server that is already disconnected will be ignored. No error will result.
No | Type | Req/ Opt | Description | Min Len | Max Len | Min Dec | Max Dec |
|---|---|---|---|---|---|---|---|
1 | A | Req | SSN of a defined server | 1 | 10 |
No | Type | Req/ Opt | Description | Min Len | Max Len | Min Dec | Max Dec |
|---|---|---|---|---|---|---|---|
1 | A | Req | Return Code. OK - Disconnection Completed. ER - Error during Disconnection | 2 | 2 |
Disconnecting a server while it is in use (e.g. in the middle of a SELECT loop when the file being selected is connected to the server) will cause application failures.
It is very strongly recommended that all "disconnect" logic is coded in one and only one function, rather than scattered and repeated through many RDML functions. This approach will isolate your application from future changes to the server(s) that are being used.
There is no real need to disconnect server(s). As the X_RUN command is terminating it will automatically disconnect any connected servers.
When executing against a database server, the actual connections to the database are dropped, but if more IO is performed against the database the connections will be re-established automatically.
It is very strongly recommended that you avoid building complex error handling schemes into your applications. Use a very simple trap like this at all levels of your application.
if (#retcode *ne OK)
abort msgtxt('Failed to .............................')
endif
Let the standard error handling Built-In Function to every generated application take care of the problem. Situations have arisen where user defined error handling logic has become so complex as to consume 40 - 50% of all RDML code (with no obvious benefit to the application). Do not fall into this trap.