Ask yourself an architectural question, " What does the delphi developed client (assuming a thick client architecture) connect to as it's next upstream component?" The answer to this will provide a map of possible options for the API used to connect to the host. You can then layer these options over the available interfaces in LoadRunner. Also, look at the installation guide. If it mentioned certain items that have to be installed as pre-requisites, such as the DB2 client, then take this as a giant architectural hint for which direction you need to look. The development environment is rarely an issue. Over the past two decades I have helped companies test software under load developed in COBOL, PowerBuilder, Turbo Pascal, C, VB, VB++, C++, C#, Clarion, Erlang, and likely a dozen others. The key is the common communication or API set leveraged by all of the languages. This is why it is key that, as a a performance tester, you have really honed client side architecture and development skills to allow you to visualize these layers between API's and standardized interfaces for how a client communicates with a server. For all we know your Delphi client could be leveraging a web services interface, in which case you would elect web or web services as the virtual user type. Or, it could be communicating with a custom sockets host, in which winsock is the way to proceed. It could even be connecting to DB2, ORACLE, SQL Server using either native interfaces or mapping layer interfaces such as ODBC, in which case you have a different path. The language for development in all cases could stay the same, but the interfaces and API sets leveraged in the application architecture dictate how. I have never run across an application I could not test. The level of development pain is higher for some interfaces than others to accurately reproduce a client. But the default assumption should be, "yes, there is a way for LoadRunner to reproduce the client conversation for my application." You just need to identify the path to success.
