LNK2019: unresolved external symbol _RfcOpenEx

[Former Member]

Hi,

• i downloaded the SAP RFC SDK 7.20 unicode (Windows Server on IA32 32bit)

• opened VisualStudio 2010

• created new MFC dialog based project

• added additional include directories (linked to SDK folder)

• added additional library folders (also linked to SDK directory)

• added librfc32u.lib;libsapucum.lib as additional dependency

• added #include "saprfc.h"

• put some code into the project

void CsaprfcsdkDlg::OnBnClickedButton1()

{

RFC_HANDLE rfc_handle;

RFC_ERROR_INFO_EX rfc_err_inf_ex;

rfc_handle = RfcOpenEx("",&rfc_err_inf_ex);

}

and tried to compile ... the result is an error that the external symbol RfcOpenEx is unresolved.

1>------ Build started: Project: saprfcsdk, Configuration: Debug Win32 -

---

1> saprfcsdkDlg.cpp

1>saprfcsdkDlg.obj : error LNK2019: unresolved external symbol _RfcOpenEx@8 referenced in function "public: void __thiscall CsaprfcsdkDlg::OnBnClickedButton1(void)" (?OnBnClickedButton1@CsaprfcsdkDlg@@QAEXXZ)

1>...\saprfcsdk\Debug\saprfcsdk.exe : fatal error LNK1120: 1 unresolved externals

========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Anyone has an idea what i am doing wrong ?

I have a Win7 64Bit running but i also tried it on VS2003 and WinXP ... but got the same error.

Thanks for your hints.

[Former Member]

Hi,

I also have exactly the same linker-problems, after I adapted our sourcecode

to be unicode-conform. A simple test-solution within a

VisualStudio 2010 environment (Win7/64bit) using librfc32u.dll

caused the same error-message.

Looking for solutions of similar problems within the WEB had no succeed.

Thanks for any hint!

[Former Member]

what i have found is ....

in the saprfc.h is an define for unicode .... maybe it is enough to set the "SAPwithUNICODE"

an alternative would be that Stephan Sell will write an answer here

When you have any test results i would be interested if it works ...

#ifndef RFC_API_ENTRY

1. if defined(SAPwithUNICODE)

/* we have UNICODE */

1. define RFC_API_ENTRY(fn) fn##U

/* Stephan Sell - 29.07.2008 */

/* disabled due to change (CL 1000445) in sapgendef.pl */

/* # elif defined(SAPonOS390) && defined(SAPwithCHAR_ASCII) */

/* */

/* OS/390 with ASCII char */

/* # define RFC_API_ENTRY(fn) fn##A */

1. else

/* default native char type */

1. define RFC_API_ENTRY(fn) fn

1. endif

#endif

Regards Frank

[Former Member]

Hi Frank,

thanks for your reply!

I did the changes suggested by Stephan,

but without any effect. I also set the 'SAPwithUNICODE'

compile-option within the test-app before.

I found some hints within the WEB which solved such problems, either to copy

the relevant files (librfc32u.dll, libsapucum.dll, ...) directly into the

windows/systemXX-directory or to use the whole PathFile-names

within the project's additional include- and library-directories.

Somebody with a similar problem had success when he set the compile-option 'Treat WChar_t As Built in Type'

to 'No (/Zc:wchar_t-)' - but I get still the linker-error.

I also checked, if the proper RFC-functions are really available within librfc32u.dll.

At the moment I have no further idea.

Regards,

Bernhard

[Former Member]

Hey Bernhard,

i made a test and this test was successful. It is more or less a workaround but maybe it helps.

I used the non unicode SDK and opened a RFC connection, called a self written function to retrieve data.

After calling the RfcCallReceiveEx i made a MultibyteToWideChar to convert all the received stuff to utf-8.

Before the conversion i got this:

el. Nr.: 00xxxxxxxxxxx

*Person:

Herr Frank é«u02DCæu2013°åu0152ºæ¨ªå±±è·¯106号 Wüldemann

*Firma:

CRM-TEST Name 2

64293 Darmstadt

DE

*Extras:

Rating: Ba

Firma-Nr.: 0003010048

Person-Nr: 0003010069

After the conversion i got this : (don't wonder first name is a test with asian characters)

http://www.l2server.de/unicode.jpg

I would imagine when you make an Widechartomultibyte before sending information to the SAP system you could receive the correct input also.

Maybe this will help you to.

Regards Frank

• snip code ***

CString CCTICallHandler::ReadDataFromSAP(CString sANum, CString sHost, CString sSysNr, CString sUser, CString sPwd)

{

try

{

if(sHost==_T("") || sSysNr==_T("") || sUser==_T("") || sPwd==_T(""))

return _T("");

RFC_HANDLE rfc_handle;

RFC_ERROR_INFO_EX rfc_err_inf_ex;

CString sConnStr;

sConnStr.Format(_T("ASHOST=%s CLIENT=100 USER=%s PASSWD=%s LANG=E SYSNR=%s TRACE=0"),sHost,sUser,sPwd,sSysNr);

rfc_char_t * conn_str = (rfc_char_t*)malloc(sConnStr.GetLength()+1);

WideCharToMultiByte(CP_ACP,0,sConnStr,sConnStr.GetLength()1,conn_str,sConnStr.GetLength()1,"",FALSE);

rfc_handle = RfcOpenEx(conn_str,&rfc_err_inf_ex);

if(rfc_handle != 0)

{

rfc_char_t function_name[] = "Z_HBM_CTI_FIND_BP_BY_NUMBER";

rfc_char_t * exception = NULL;

RFC_RC rfc_rc;

char * chANum = (char*)malloc(sANum.GetLength()+1);

int sz = sANum.GetLength() + 1;

WideCharToMultiByte(CP_ACP,0,sANum,sz,chANum,sz,"",FALSE);

RFC_PARAMETER importing[2],exporting[2];

RFC_STRING value1 = (RFC_STRING)chANum;//m_sANumber;

RFC_STRING value2;

exporting[0].name = "TEL_NUMBER";

exporting[0].nlen = strlen (exporting[0]. name);

exporting[0].type = RFCTYPE_STRING;

exporting[0].addr = &value1;

exporting[0].leng = sizeof(value1);

exporting[1].name = NULL;

importing[0].name = "RESULT";

importing[0].nlen = strlen(importing[0].name);

importing[0].addr = &value2;

importing[0].type = RFCTYPE_STRING;

importing[1].name = NULL;

rfc_rc = RfcCallReceiveEx(rfc_handle, function_name, exporting, importing, NULL, NULL ,&exception);

RfcClose(rfc_handle);

free(chANum);

free(conn_str);

CString sRetVal;

MultiByteToWideChar(CP_UTF8, 0, (LPCSTR)value2,-1, sRetVal.GetBuffer(strlen((const char *)value2)), strlen((const char *)value2));

sRetVal.ReleaseBuffer(strlen((const char *)value2));

return sRetVal;

}

else

return _T("Connection to CRM failed.");

}

CRML_CATCH_UNI_RET_EMPTY

}

• snip code end ***

[Former Member]

Hello Frank,

thanks for your helpful workaround, although I would prefer

to move within a complete UNICODE envionment.

If I cannot solve the linker-problems I'll consider your idea.

Regards,

Bernhard