So how does your script communicate with the database engine? It calls a set of ODBC functions in an add-on dynamic link library (DLL) named RxOdbc (RXODBC.DLL). RxOdbc is actually an "ODBC Manager". It manages a whole bunch of ODBC "drivers" for various database engines. For example, it can manage the driver for Microsoft Excel so that when your script calls the ODBC functions in RxOdbc, you communicate with Microsoft's Excel program. The ODBC Manager (RxOdbc) can also manage the driver for Oracle, so that when your script calls the very same functions in RxOdbc, you communicate with Oracle's database software. Your script (indirectly) tells the ODBC Manager which driver you want to use, and then when your script calls the ODBC Manager's functions, the manager communicates with the appropriate database engine.
As long as your database software has an ODBC driver for it, then you can interact with it (through the functions in RxOdbc) in the same way as any other database engine.
If the database that you're interacting with is across some network, RxOdbc does all of the work of shipping data back and forth across the network. You merely call some ODBC function to "send" a command or some data to the database engine, and you call another ODBC function to "read" the data that the database engine may return to you. You do not need to know anything about network protocols, nor write code to establish a connection to some server. RxOdbc takes care of these details. RxOdbc has functions to "connect" to a database (and will connect to whatever server the database may be on), send a "command string" or data to the database engine, and receive back data from the database engine.