Problem of OCI calls in DLL

Hi,
I am developing a DLL in which i am using OCI calls to interact with Oracle. The Logon oci call "olog" itself fails when it is called from DLL. It is working fine in EXE. Whether OCI calls can be used in DLL? If so, let me know how to use it. If not, whether OCI calls can be used in COM or CORBA components?
Thanks in advance.
Ravi
null

This is not a forum for OCI, but interMedia. Please look for an appropriate forum and post there. Also, I recommend to include your system envirment information in your post.

Similar Messages

  • Problem with OCI call  and  how to install and use 'DEBUG_EXTPROC' on Linux

    Hi,
    Can any one let me know how I can install and use this debug_extproc package. I have installed oracle XE server on Linux machine(32-bit).
    When I use : DEBUG_EXTPROC.STARTUP_EXTPROC_AGENT' ... i get an error saying that : it is not declared.
    I tried looking in all the directories but did not find the dbgextp.sql(which is required in order to install that package).And tried searching on google but could not get any relevant information.
    Also I am newbie to OCI call interface and also to C programming too: I have coded a external procedure or custom user aggregate in C. But since I was using C++ : 'set' STL. I have compiled my program using g++ instead of gcc and I have correspondingly modified the make file in public/demo directory.
    So, is it fine to do it that way: using OCI (instead of OCCI(C++)) but again compiling the pgm as a regular C++ using g++ instead of gcc.(But rest of the pgm including printf statements : everything is in C).
    Also I have created the library from my : custagg.so library:
    SQL> create or replace library custagg is '$ORACLE_HOME/lib/custagg.so'
    But my aggregate function implemented as external C function using OCI is either not recognised or else : if recognized then there is some error because of which i am getting the following errors : ORA-06522
    SQL> select MinDistance(TT) from egg1;
    select MinDistance(TT) from egg1
    ERROR at line 1:
    ORA-06520: PL/SQL: Error loading external library
    ORA-06522: /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/custagg.so:
    cannot dynamically load executable
    Please kindly answers my queries and trying to resolve this for almost 4 days now and could not find any clue on how to get this done.
    Thanks,
    -NN

    #/bin/make
    # Make file for OCI,OCCI and ODBC demos
    # Usage :
    # For compiling & linking the cdemo81.c file
    # make -f demo_xe.mk buildoci CDEMOEXE=cdemo81 CDEMOOBJS=cdemo81.o
    .SUFFIXES: .o .c .cpp
    ICINCHOME=$(ORACLE_HOME)/rdbms/public/
    ICLIBHOME=$(ORACLE_HOME)/lib
    ICLIBPATH=-L$(ICLIBHOME)
    THREADLIBS=-lthread
    CCLIB=$(ICLIBPATH) -lclntsh $(THREADLIBS)
    OCCILIB=$(ICLIBPATH) -locci -lclntsh $(THREADLIBS)
    CCINCLUDES = -I$(ICINCHOME)
    CCFLAGS=$(CCINCLUDES) -D_REENTRANT -g -xs
    LDFLAGS=
    SO_EXT=.so
    EXTLDFLAGS=$(LDFLAGS) -shared
    REMOVE=rm -rf
    MKLINK=ln
    MAKE=make
    MAKEFILE=demo_xe.mk
    CDEMOEXE=custagg.so
    CDEMOOBJS=custagg.o
    OCCIDEMO=occidml
    OCCIOBJDEMO=occiobj
    OTT=$(ORACLE_HOME)/bin/ott
    OCCIOTTUSR=hr
    OCCIOTTPWD=hr
    ODBCDEMOEXE=odbcdemo
    ODBCDEMOOBJS=odbcdemo.o
    AQDEMOEXE=ociaqdemo00
    AQDEMOOBJS=ociaqdemo00.o
    EXTDEMO=extdemo2.so
    CC=/usr/bin/g++
    echo "LIBCLNT value is :" $(LIBCLNT)
    echo "CC value is :" $(CC)
    .c.o:
    g++ -c -I$(ICINCHOME) $(CCFLAGS) $<
    all: clean buildoci
    echo "LIBCLNT value is :" $(LIBCLNT)
    buildoci: $(LIBCLNT) $(CDEMOOBJS)
    g++ -o $(CDEMOEXE) $(LDFLAGS) $(CDEMOOBJS) $(CCLIB)
    echo "CC value is :" $(CC)
    echo "LIBCLNT value is :" $(LIBCLNT)
    clean:
    $(REMOVE) $(CDEMOOBJS) $(CDEMOEXE)
    # This port-specific file is currently empty on Solaris. Product
    # lines may use this file to override compiler definitions and
    # flags used in occi.mk.
    # Linux compiler definitions
    CC=/usr/bin/gcc
    cc=/usr/bin/gcc
    CCFLAGS=$(CCINCLUDES) -DLINUX -D_GNU_SOURCE -D_REENTRANT -g
    LDFLAGS=-g
    # This macro CCINCLUDES has to be redefined on Linux because of
    # the existence of the 'new' directory in t_work. The name new
    # clashes with a system header file.
    CCINCLUDES = -idirafter .
    THREADLIBS=-lpthread
    ifdef BUILD_CCC296
    CC=/usr/bin/g++296
    endif
    And I am executing the make file using the command :
    make -f demo12.mk buildoci CDEMOEXE=custagg.so CDEMOOBJS=custagg.o
    I am not getting any error while running this make file.
    Can you please tell me whether PLSQL/Oracle is able to locate the file or not. Incase, if it is locating the file but due to some error in the custagg.so it is throwing that error. If this is the case, is there any way that i can debug the C program .....how can i install the debug_extproc package.. I am really new to C & OCI ... if the custagg.so is being located then there might be some problem with the way I am dynamically allocating memory to some variables.
    Please kindly reply to this Post/response.
    Please let me know if you also want to see my program code.
    Thanks & Regards,
    -NN

  • Intermittent problem with TestStand calling CVI DLL calling MSCV DLL

    Sorry about cross post, but I am not sure which group is best to address
    this issue.
    Setup:
    Windows 2000 SP1
    TestStand 2.01f
    CVI 6.0
    MSVC++ 6.0 SP5
    Problem:
    I have a CVI Test Library DLL that contains test functions called by
    TestStand using the C/CVI adapter. The CVI Test Library DLL in turn makes
    several calls to another DLL written in MSVC++. I am experiencing an
    intermittent problem with one of the MSVC functions. The problem ~appears~
    to be stack related, but I am not sure. Among other things, this MSVC
    function accepts a const char * argument that is a TestStand lookup string.
    The function uses this string to access the TestStand API.
    What happens is this: Everything works fine. I then recompile the CVI DLL
    after making some mod, then run. The MSVC++ DLL asserts that the const char
    * arg passed by the CVI DLL is NULL. However, this is not the case if I
    single step through the CVI code. It has happened both with passing
    variables as the const char * argument and as hardcoded strings literals, so
    its not that I am actually passing NULL. The other argument to this
    function is the TestStand sequence context dispatch pointer (LPDISPATCH
    pobjSequenceContextDisp) and it always ~appears~ to be passed correctly.
    The problem is frustrating and hard to debug because I can not
    deterministically reproduce it. The problem ~never~ appears when I debug my
    MSVC++ DLL in Visual Studio. And it only occasionally appears otherwise.
    The problem, when it appears, always appears on the first run after
    recompiling the CVI DLL, though the problem does not happen after ~every~
    recompilation. I'd say it happens 1 in 6 times after a recompile.
    Recompiling the exact same code does not always make the problem disappear.
    If I change the CVI code (code that has nothing to do with the argument
    itself though) and recompile the problem almost always goes away. Selecting
    'Mark all for compilation' and rebuilding does not make the problem go away.
    Only tweaking the CVI code and recompiling does (usually).
    Whats more, the problem appears:
    * With the CVI DLL built as Debug or Release mode.
    * With the CVI default calling convention set to __stdcall or __cdecl.
    * With the C/CVI TestStand adapter set to run in-process or external
    instance of CVI.
    The problem appears to be some sort of stack or argument passing problem
    between CVI and MSVC, though thats just a guess based on the symptoms. I
    have quadruple checked the calling conventions of all declared functions.
    The CVI DLL functions all use TX_TEST (which resolves to __cdecl). The MSVC
    DLL functions all explicitly use __stdcall. Is there a problem with calling
    __stdcall MSVC functions from a __cdecl CVI function?
    I can find no other memory leaks or indications of memory corruption
    elsewhere in either the CVI or MSVC DLLs. Its only this one function that
    exhibits this strange 'null const char *' problem.
    Can anyone offer any ideas about what may be causing this problem? Anything
    else I should check/verify?
    Regards,
    Joe

    Silvius,
    > Although I'm not sure if any of the following are the real cause of
    > your problem, I have the following suggestions:
    Thanks for the reply. At this point any and all suggestions are welcome...
    > 1. There could be a problem with calling
    > __stdcall MSVC functions from a __cdecl CVI function. As a workaround
    > wrap the _cdecl call inside a _stdcall call that is exposed or
    > exported to TestStand or vice-versa. This can be a problem because if
    > _cdecl is used, the calling function is responsible for cleaning up
    > the stack and if _stdcall is used, the called function is responsible
    > for cleaning up the stack.
    I was under the impression that as long as everything was explicitly and
    consistently declared, you could safely mix cdecl and stdcall f
    unction
    calls. Is it bad to do this? Is this a known issue with the CVI compiler?
    I've never seen a problem with doing this under MSVC++.
    I'll try wrapping them in cdecl calls for CVI - though we have a
    depressingly large number of stdcall functions in the MSVC DLL ;-). They
    need to remain stdcall in the DLL because we also call them from Visual
    Basic.
    > 2.Don't mix Debug version of one DLL with the Release version of the
    > other DLL. I had some bad experiences doing this and both DLLs where
    > developed in MSVC. Allways use either Debug either Release versions of
    > DLLs.
    I verified that the MSVC DLLs were either ALL Debug or Release. I too have
    seen nasty problems when MSVC Debug and Release is mixed.
    One thing I had not thought of until your reply: What about mixing CVI Debug
    DLLs with MSVC Release DLLs? Have you ever seen issues with doing this?
    Thanks!
    Joe

  • Problem about calling a DLL in LABVIEW

    Hi,
    I have a problem using Labview to call a DLL file, when I call the function " commandinterp() in labview, labview will always return error message"an error occured in external code, it might  have corrupted labview memory..."  attached is the DLL file and the labview code .so did the code i attached have any problem? or is it the problem of the DLL?  thanks
    Attachments:
    mydll.txt ‏22 KB
    callfunctionnode.vi ‏7 KB

    It looks to me that he might be missing an input parameter. 
    The line shows   int commandinterp (char cmd_line[]) {
    So is a char type an input argument for the function to be used as the variable name cmd_line?
    The attached VI does not show any input parameters doing into the DLL call.
    (I am not entirely sure.  Since the dll itself was not attached, I had to tell Labview to ignore the item when it looked for it.  Perhaps the way the VI opens up when the dll doesn't exist on my machine is different then if the dll did exist.)
    Message Edited by Ravens Fan on 07-20-2007 12:01 AM

  • Forms 6.0/user_exit call to DLL--Thoughts anyone?

    I have 6.0 Forms that call to DLL functions where the DLL was built using MS VC++ 5.0--works fine.
    Upgraded to MS VC++ 6.0 and rebuilt DLL (no code changes). Pointed FORMS60_USEREXITS registry to new DLL but now get the following message when trying to call any functions from the new DLL:
    FRM-40800 User exit <somename> does not exist.
    Anyone?
    TIA

    It has been a while since I fixed this problem, but I think you have to run FRM50SEC.sql and then grant select on the FRM50_ENABLED_ROLES view to your target audience.
    Try This...
    create or replace view FRM50_ENABLED_ROLES as
    select urp.granted_role role,
    sum(distinct decode(rrp.granted_role,
    'ORAFORMS$OSC',2,
    'ORAFORMS$BGM',4,
    'ORAFORMS$DBG',1,0)) flag
    from sys.user_role_privs urp, role_role_privs rrp
    where urp.granted_role = rrp.role (+)
    and urp.granted_role not like 'ORAFORMS$%'
    group by urp.granted_role;
    create public synonym FRM50_ENABLED_ROLES for system.FRM50_ENABLED_ROLES;
    create role ORAFORMS$OSC;
    create role ORAFORMS$DBG;
    create role ORAFORMS$BGM;
    -- Added
    grant select on frm50_enabled_roles to public;
    null

  • File not found when trying to call a dll on LabVIEW Real Time machine

    I have a dll called "DLLRTTEST" that I've written, and have succesfully called on my host machine.  I'm now attempting to call this dll from a vi that is located on my real time computer.  Currently I get an "Error 7 occurred at Call Library Function Node in DLLRTTEST.vi." message upon execution
    In the attached screenshot I'm trying to ensure that the vi I'm running is in fact located on the real time system.  I then use a "Check if File or Folder Exists.vi" to confirm that the dll that I'm about to call does exist on the real time system as well.  However, I still receive an "error 7 file not found" error from the Call Library Function Node.
    Any help is appreciated.
    Solved!
    Go to Solution.
    Attachments:
    DLL_Call_Screenshot.png ‏61 KB
    DLL_Call_Screenshot.png ‏61 KB

    As nathand already mentioned, depending on your C toolchain your DLL will depend on other DLLs. Usually the according msvcrtXX.dll that matches your Visual C version, if you use Visual C, other runtime DLLs if you use a different C environment. These runtime DLLs are even necessary if you do not call anything in any of your functions, since the DLL makes various initialization steps when it gets loaded and that references some C runtime functions nevertheless. Compiling and linking the DLL with static C runtime is usually also not a clean solution since the linked in C runtime will then reference Windows APIs that are not available on LabVIEW RT.
    Depending on your version of LabVIEW RT you will have some mscvrtxx.dll files in your system directory but it will be an older one than from the latest Visual Studio version. If you can compile your DLL with that Visual Studio version then you should be fine, but could possibly run into new problems if you later upgrade to a newer LabVIEW RT version. Installing the C runtime distributables from newer Visual Studio versions is unfortunately also not a solution, since it references many (undocumented) Windows API functions that are not available in LabVIEW RT.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Security exception when trying to call a DLL from an applet

    Hi all,
    I really hope someone out there can help me. I'm trying to call a windows DLL from an applet but always get some error when the call to the DLL comes. If I run it on the command line (calling a dummy main function that only calls the dll) I don't get any error. However, with the -Djava.security.manager, I get an ExceptionInitialiserError. When running it in a browser, I seem to get any of three errors, the above, securityAccessControlException (as I was expecting) and even NoClassDefFoundError.
    I realise of course that this has to do with the permissions in effect but nothing seems to happen when I change the policy file, so I have to feeling that I'm chaning the wrong file. The one I'm using is the one the JRE entry in the registry is pointing to, Java Runtime Environment->CurrentVersion...
    I even tried giving everything in the applet's directory AllPermission.
    So what I'm wondering is this. Is there any way to check if your policies are actually working and when you update the files, what do you need to do to make the changes take effect?
    Best regards,
    G�sli

    I have the same problem. Have you solved your problem, if so please let me know what the solution is.
    Einar �rn

  • Can LabVIEW call a DLL built with VS(2005) C++ with /CLR and Without an Entry Point

    My project requires me to convert a C++ program to a DLL and having it called by LabVIEW. Due to the complexity of this C++ program (converted from fortran using f2c -C++ option), it cannot be compiled without using /clr option.  I did build the application standalone (/clr), and it functioned fine.  When I build it into DLL using VS2005, I was forced to use No Entry point option and without using DllMain in the C++ code. Eventually the DLL was built without error.  But after I call it from LabVIEW, I was not getting calculated results as expected.  I added a testing function to the C++ code of the DLL and just try to modify a parameter, it will not, but only return the input numbers.  I was passing data by pointer and not by value, so I expect this parameter output be modified.  I suspect that the DLL didnt get executed at all as it has no entry point specified.
    Am I on the right track to approach this task, or I am heading to totally wrong direction here?   I believe due to the fact that my C++ was from f2c and use vsf2c.lib and so on, the code is managed code, so that a regular DLL cannot be built from it with an entry point. How can LabVIEW call such a DLL? Am I right on that?  I really need your advice here for a right approach to this problem and possible implementation "watch outs"...Thanks!
    Bryan

    Hi...Finally I was able to compile my code with an entry point defined and without using /clr.  I can also call this DLL from LV and got back a variable from a little test function added to the DLL.  But the function that was used for my main application in the DLL crashed LV and I got a pop up box from Microsoft Visual C++ Runtime Library: Runtime Error! "This application has requested the Runtime to terminate it in an unusual way, please contact the application's support team for more information".  In Visual Studio I also got the following message: (I eliminated most of the "No symbols loaded" messages that are not errors but just info.)  I would apprciate if someone can take to look with your more "experienced eyes", many thanks! Bryan.
    'LabVIEW.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\xpsp2res.dll', Binary was not built with debug information.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\Shared\nicont.dll', Binary was not built with debug information.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\Shared\NICONTDT.dll', Binary was not built with debug information.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\nitaglv.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\lkbrow.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\lkrealt.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvdaq.mxx', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvdesktop.mxx', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvfp.mxx', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\mfc71.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\MFC71ENU.DLL', Binary was not built with debug information.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\vi.lib\FieldPoint\SubVIs\FPLVMgr.dll', Binary was not built with debug information.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvfprt.mxx', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\LvProjectProxy.mxx', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\LvRealTimeCoreProvider.mxx', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\MVEProvider.mxx', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\QtCore4.dll', Binary was not built with debug information.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\QtXml4.dll', Binary was not built with debug information.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\QtGui4.dll', Binary was not built with debug information.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\mxLvProvider.mxx', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\nimxlcpp.mxx', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\nimxlc.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\variable.mxx', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\lvMax.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\MAX\UI Providers\FieldPoint71.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\MathScriptParser.dll', Binary was not built with debug information.
    'LabVIEW.exe': Loaded 'Z:\bli\development\projects\galfitDLL\Debug\galfitDLL.dll', Symbols loaded.
    'LabVIEW.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcr80.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\mesa.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\mscms.dll', No symbols loaded.
    'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\icm32.dll', No symbols loaded.
    The thread 'Win32 Thread' (0xf94) has exited with code 0 (0x0).
    The thread 'Win32 Thread' (0x90c) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0xfd0) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0x284) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0xdac) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0xa98) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0x528) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0x614) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0xa5c) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0xebc) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0x5cc) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0x700) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0xcf0) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0xc7c) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0x4c8) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0xa4) has exited with code 3 (0x3).
    The thread 'Win32 Thread' (0x52c) has exited with code 3 (0x3).
    The program '[804] LabVIEW.exe: Native' has exited with code 3 (0x3).

  • How can i call a DLL file from labview?

    Iam using a sensoray 2601 module.It is given as DLL file(S2600.DLL).How can i call this function from LabVIEW?
    Please Mark the solution as accepted if your problem is solved and donate kudoes

    As far as I can tell problems might occur with the call library function node if the the DLL from visual basic is actually an ActiveX dll if that is the case it seems calling the dll by using the Invoke node is the way to go.
    Have a look at this 
    /sletten

  • Error in Calling a dll built in labview from Matlab standalone

    hello,
    The problem I encountered is in the use of the math interface toolkit. I
    created a dll which performs data fitting using a labview vi which i converted into a dll using the
    math interface toolkit.
    This dll is then called from a standalone matlab program. It works fine in the computer where I
    create the matlab standalone program and labview dll. Howerver when i export to another
    computer the matlab part runs fine but an error is reported when it tries to
    call the labview created dll.
    "One or more output arguments not assigned during call Parfit.dll"
    The files related to this problem in the math interface toolkit (the labview vi, the corresponding dll and the matlab .m and .fig files and the standalone exe are in the attachment and named MathITproblem.zip
    The matlab run time engine(for matlab 7) and labview runtime engine(ver 7.1) must be installed for this matlab file to run. the run time engines are downloadable from the web.
    Does any one know the source of this error or encountered it before?
    thanks
    Attachments:
    MathITproblem.zip ‏1263 KB

    Hi Srinivas,
    Just another note, I noticed that the Math Interface Toolkit version (MIT) 1.0 is not compatible with LabVIEW 7.1. You’ll need version 1.0.1. of the MIT toolkit in order for it to work with LabVIEW 7.1.
    The LabVIEW 7.0 lvanlys.dll is also attached. I had to rename it with a .txt extension, so you’ll want to delete the extension.
    Kileen
    Attachments:
    lvanlys.dll.txt ‏516 KB

  • OCI CALLS : Oracle 8.1.5 to Oracle 8.1.6

    Hi
    I am working on messaging product which was compiled and linked with Oracle 8.1.5. It was working on HPUX 11.0 machine. That product is a CORBA product which uses ORCALE to store message database. This product uses OCI calls to access ORACLE.
    But I am having a new task of running that product on oracle 8.1.6 version. When I ran old bineries(compiled and built with oracle 8.1.5 libs) with oracle 8.1.6 product, I am getting following runtime errors. DBINIT is a executable.
    $PROMPT>DBINIT -v
    /usr/lib/dld.sl: Unresolved symbol: LhtStrCreate (code) from /opt/oracle/8.1.6/lib/libwtc8.sl
    /usr/lib/dld.sl: Unresolved symbol: LhtStrInsert (code) from /opt/oracle/8.1.6/lib/libwtc8.sl
    /usr/lib/dld.sl: Unresolved symbol: nauzaoss (code) from AmOraDbInit
    /usr/lib/dld.sl: Unresolved symbol: nauzaoss (code) from /opt/TPBroker/AM/lib/libAmdOra.sl
    Whether I need to compile and build whole product with oracle 8.1.6.
    In my product I am using OCI calls, so whether I need to change those calls.
    $PROMPT>chatr DBINT
    shared executable
    shared library dynamic path search:
    SHLIB_PATH enabled first
    embedded path disabled second Not Defined
    shared library list:
    dynamic /usr/lib/libpthread.1
    dynamic /vobs/TPBroker/hpux/TPBroker/lib/libots_r.sl
    dynamic /vobs/TPBroker/hpux/TPBroker/lib/libdcpmsg.sl
    dynamic /vobs/bldenv/hp11/Visigenic/vbroker/lib/liborb_r.sl
    dynamic /vobs/bldenv/hp11/Oracle/lib/libclntsh.sl.8.0
    dynamic /usr/lib/libstd.2
    dynamic /usr/lib/libstream.2
    dynamic /usr/lib/libCsup.2
    dynamic /usr/lib/libm.2
    dynamic /usr/lib/libcl.2
    dynamic /usr/lib/libc.2
    static /usr/lib/libdld.2
    shared library binding:
    immediate
    global hash table disabled
    plabel caching disabled
    global hash array size:1103
    global hash array nbuckets:3
    shared vtable support disabled
    static branch prediction disabled
    executable from stack: D (default)
    kernel assisted branch prediction enabled
    lazy swap allocation disabled
    I haven't got any documents for this thing.
    If anybody gone thru this problem, please help me for solving this problems.
    Thank you
    -Pravin

    applets can only use jdbc thin drivers.

  • Calling a dll created with vision 7.0 from visual basic doesn't work

    I created a dll using some vision 7.0 functions and Labview 7.0 environment. I call this dll from visual basic. The dll will work fine as long as I don't stop the visual basic program execution. As soon as I stop the program execution the dll will no longer work. I must reload the visual basic environment and the call to the dll will start working again. I created the exact same dll but I created it with vision 6.0 in Labview 6i environment. It works great and has no issues.
    Attachments:
    Test.vi ‏36 KB

    Roberto N. wrote:
    Thank you Jordan, I'm using Labview 7.1.
    Anyway I've resolved the problem by adding the "lvanlys.dll" file (present in "..\Labview 7.1\resource\lvanlys.dll" path) as support file in the building process. Now the DLL containing the analysis functions works correctly.
    Natalino Roberto
    Ok, you probably got lucky since the lvanlys.dll seems to implement that function directly. However most Advanced Analysis functions are just redirected by lvanlys.dll to the Intel Math Kerneal Library that gets installed with LabVIEW 7.1 and higher. The only way to get that properly installed with your LabVIEW executable or DLL is to create a LabVIEW installer in your Application Builder and make sure to select under "Installer Settings->Advanced" the "LabVIEW Run-Time Engine" and the "Analyze VIs Support". Then use that installer to install your DLL on another computer.
    Rolf Kalbermatter
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Calling a DLL(with vi.lib) from a lvclass within a Packed library

    Basically, I am having problem calling a DLL (which uses the vi.lib) from a packed library.
    The error code I got is error code 1003. “Error 1003 occurred at Call Library Function Node in XXXXX.lvlibp”, “Labview: The VI is not excutable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.   Create Summary Log.vi”
    The VI that was mentioned above (Create Summary Log.vi) is one of the functions in the DLL that I am trying to call from the packed library. This VI modifies an Excel spreadsheet so it needs the vi.lib. In my DLL project, vi.lib is in my dependencies. When I compile my DLL, Labview will create four folders (NI_Excel, NI_HTML, NI_report, NI_Standard Report) at the build destination.  
    To problem happens when I run a Top level VI, which calls-> the lvlibp -> lvclass (within the packed library) -> DLL (uses the vi.lib Excel functions).
    This problem doesn’t happen when I am not running the packed library (Only with the lvclass). So I think the problem is that DLL can’t access or find the vi.lib when it’s being called by the packed library. It seems like the packed library changes the way the DLL access the vi.lib.
    Any suggestions?

    Hi,
    Thank you for your reply. Unfortunately, I think I might have provided wrong information. I thought the problem didn’t exist when I wasn’t running the packed library, but the truth is, the problem always exist regardless.
    I would get an “error 7” when I created a simple VI that would utilize “Call Library Function Node” to call the DLL.  
    Error 7 occurred at Get LV Class Default Value.vi
    Possible reason(s):
    LabVIEW:  File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS X, and / on Linux. Verify that the path is correct using the command prompt or file explorer.
    =========================
    NI-488:  Nonexistent GPIB interface.
    Complete call chain:
         Get LV Class Default Value.vi
         NI_report.lvclass:New Report.vi
         Create Summary Log.vi
         Create Summary Log.vi.ProxyCaller
    LabVIEW attempted to load the class at this path:
    C:\XXX\XXX.dll\Excel\NI_Excel.lvclass
    So the problem is, I don’t know how to include the NI_Excel.lvclass in my DLL. I didn’t have this problem back in 8.2, as I would just include a VI (with the excel VIs in the block diagram) in the project when I build it. This doesn’t work anymore as I am using 2011. 

  • OCI calls failing for Oracle 11g 11.1.0.7 (64 bit)

    Hi,
    I have a 32bit app which we build and compile in a 32 bit OS, we then deploy this in a 64 bit Windows 2008 R1 machine which has a 11g 64 bit DB;
    when the code make the OCI calls the app terminates.On debugging we found out that its failing to make OCI calls on the connect() method of a .cpp file.
    This connect code is a custom wrapper class created for OCI which only accepts a complete SQL statement mainly used for looking after rollback segments, etc.
    The code runs perfectly fine when we internally call the ORACMD of sqlplus and directly execute the sql from a script.
    It only fails when our code tries to connect to the DB and make OCI calls.
    I have also installed a 32 bit Oracle 11g Client 11.1.0.7 since I am using a 32 bit app.
    Is there any compatibility issues between these 2 versions or the dll's?
    Why is it failing while making OCI calls and is there any resolution?
    My machine and setup details:
    OS: Windows 2008 R1
    DB : Oracle 11g R1 11.1.0.7 (64 bit)
    Client: Oracle 11g R1 11.1.0.7 (32 bit)
    Our App: 32 bit
    ORACLE_HOME = // this is pointing to the 64 bit DB
    I tried pointing the oracle_home to the client still no go.
    Any suggestions on this will be appreciated.
    Regards
    Roy

    user13376823 wrote:
    how do i find that my database is using big file tablespace management or not ?
    SQL> select TABLESPACE_NAME,BIGFILE from dba_tablespaces;
    TABLESPACE_NAME                BIG
    SYSTEM                         NO
    UNDOTBS1                       NO
    SYSAUX                         NO
    USERS                          NO
    UNDOTBS2                       NO
    TEMP1                          NO
    TEMP3                          NO
    TEMP2                          NO
    8 rows selected.For tablespaces with smallfile datafile maximun datafile size is 32GB, where as bigfile datafile size is 8 exabytes.

  • How to give call to dll in indesign plugin

    Hello All ,
    I am developing one indesign plugin on Mac OS X 10.4.
    I want to give a call to one dll in pluging code.
    But the problem with mac os x according to my knowladge ,dll need to be build in same project where we are calling that dll.
    That is why I build a xyz.dylib in same project for indesign plugin as one of the target. and I am coping it in Indesignplugin package content that is with release mode build.but dll gets build in debug mode.On Mac OS X I am using dlopen and dlsym call . But I am not able to call a dll present in indesign plugin package content. Any idea How to call a dll in indesign plugin on Mac OS X.Should we need tyo build a xyz.dylib file in release mode ?
    Thanks,
    Pallavi.

    Seems to me I don't understand something, or text format plugin isn't quite well example. But, I got some code from sdk to create layer with automation like this:
    SPErr MakeLayer(void) {
    PIActionDescriptor descriptor = NULL;
    PIActionReference reference = NULL;
    PIActionDescriptor result = NULL;
    SPErr error = kSPNoError;
    error = sPSActionDescriptor->Make(&descriptor);
    if (error)
    goto returnError;
    // Move this to the top of the routine!
    error = sPSActionReference->Make(&reference);
    if (error)
    goto returnError;
    error = sPSActionReference->PutClass(reference, classLayer);
    if (error)
    goto returnError;
    error = sPSActionDescriptor->PutReference(descriptor, keyNull, reference);
    if (error)
    goto returnError;
    error = sPSActionControl->Play(&result, eventMake, descriptor,
    plugInDialogSilent);
    if (error)
    goto returnError;
    returnError:
    if (result != NULL) sPSActionDescriptor->Free(result);
    if (descriptor != NULL) sPSActionDescriptor->Free(descriptor);
    if (reference != NULL) sPSActionReference->Free(reference);
    return error;
    and wrote aeta resource:
    resource 'aete' (16000, "myFile" " dictionary", purgeable)
    1, 0, english, roman,
    vendorName,
    "description",
    plugInClassID,
    1,
    1,
    vendorName " myFormat",
    plugInAETEComment,
    plugInClassID,
    plugInEventID,
    NO_REPLY,
    IMAGE_DIRECT_PARAMETER,
    "create",
    keyMyCreate,
    typeMyCreate,
    "create type",
    flagsEnumeratedParameter
    typeMyCreate,
    "layer",
    createLayer,
    "make layer"
    And what now? Is any better examples?

Maybe you are looking for