build from source

[Claudio Tamietto]

i have build from source xmla connect .
in addition to the readme I added the folder E:\Documents\programs\gsoap\gsoap-2.8.17\gsoap ( my gsoap installation ) to the list of include directory of Visual Studio Project .
I also replaced the file stdsoap2.cpp contained in the Visual Studio Project with that of gsoap installation .
I have build the solution with admin privileges and the com component was registered with success .
However, it does not appear in the list of oledb provider in excel .
thanks for any answer

[Alexandra Davidoiu (Iancu)]

As far as the register was successful you should see a new provider called "XMLA Data Source". Check the attachment for your reference.

Normally the behavior you describe happens when you have architecture mismatches. Like you build the provider for x64 and your Excel is 32 bits or the other way around. Please note: this is not your Windows architecture. You could very well have 64 bits Windows and 32 bits Excel installed on it. Can you check this?

Let me know if this helped.

[Claudio Tamietto]

you are right , i have compiled the provider for 32 bits and my platform and excel are 64 bits .
However , if i install your binary distribution it works ( i see the provider called "XMLA Data Source" ) .
So , i have to build the provider for 64 bits or i can register the driver odbo in a differet way ?

[Alexandra Davidoiu (Iancu)]

However , if i install your binary distribution it works ( i see the provider called "XMLA Data Source" ) .

The installer contains both 32 bit and 64 bit architectures.

For 32 bit windows we install only 32 but for 64 we install both, just in case.

[Alexandra Davidoiu (Iancu)]

Because you have 64 bits Excel you MUST have the 64 bits driver as well. You can find a 64 bit platform in the solution and it works. ( You must rebuild for 64 bit to compile)

[Claudio Tamietto]

I have build the solution with platform 64 and now it works ( i can see the povider "XMLA Data Source" ) .
I have one more question .
Can i debug the code ?
I have tried with "Attach Process" on the menu "Debug" but the breakpoint i have set show an exclmation mark and the message
"The breakpoint will not be currently be hit . No symbols have bean loaded for this document ."

[Alexandra Davidoiu (Iancu)]

I have tried with "Attach Process" on the menu "Debug" but the breakpoint i have set show an exclmation mark and the message
"The breakpoint will not be currently be hit . No symbols have bean loaded for this document ."

Yes, this is the way you should debug. Some observations:

1. With a freshly opened Excel the provider is not loaded yet. It loads on demand. The breakpoint looks the way you describe but it will work.
2. Even if you open a workbook with data you previously saved, Excel shows data from cache. You have to change something in the pivot table and then it will load.
3. The best position to place a first breakpoint is in the FinalConstruct method of the data_source or in DllMain. Those are the earliest calls made by Excel.

We also do very often another error: We install the provider from the kit then it does not debug. This is normal because the other, possibly different dll is loaded and the symbol tables don't match. Make sure the source code you use for debug is properly registered.

Let me know if this helps.

[Claudio Tamietto]

i have followed this steps :
1) removed the installation of XmlaConnect
2) compiled and installed from source ( Visual Studio running as administrator )
3) set breakpoint at the asterisk in file dllmain.cpp

extern "C" BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
* return _AtlModule.DllMain(dwReason, lpReserved);
}
4) started excel
5) attach to process from visual studio ( process EXCEL )
6) start defining a new connection ( don't reuse previous definited connection ) and drag and drop some dimension but the breakpoint is not activated .

sorry and thanks for your patience ( i'm not a c++ programmer )

[jhonew32]

Building software from source code involves compiling the program directly from its original human-readable form (usually written in languages like C, C++, or others) into machine-readable binary code. This process typically involves several steps:

Firstly, ensuring that all necessary dependencies and libraries are installed on your system is crucial. These dependencies are additional software components that the program relies on to function correctly.

Secondly, obtaining the source code itself, usually from a version control system like Git House Cleaning Raleigh or a downloadable archive. This step ensures you have the latest or a specific version of the software to build.

[giankenbellfore]

This process allows you to customize and optimize the software for your specific needs or environment. To build from source, you'll usually need to download the source code from the project's repository, which is often available on platforms like GitHub or GitLab. You'll also need to ensure that your system has the necessary development tools and libraries installed. Following the project's build instructions, which are usually detailed in a README or INSTALL file, will guide you through configuring and compiling the code for Fintechzoom-Pro. Building from source can offer greater control and flexibility, but it may require a good understanding of software development and system configuration.

[jhone smith]

Building from source means compiling software directly from its original code, rather than installing a precompiled version. This approach is often preferred by developers and advanced users who want more control over the installation, optimization, or customization of the software fenix internet on bank statement. It can lead to better performance, compatibility with specific systems, or access to the latest features before they’re officially released.