where to add the a CAN db file when creating an exe.

[griff32]

I have created an Executable file to run on a non LabView PC. When I start the file, I cannot seem to select the database when I right click on the target machine. On my development machine the exe seems to know where the db is. 

I am assuming I have installed the db on the target computer in the wrong folder. Does someone have a "best pratice" for avoiding this mistake?

Thanks

[Hooovahh]

---

@griff32 wrote:

I am assuming I have installed the db on the target computer in the wrong folder. Does someone have a "best pratice" for avoiding this mistake?  

---

This might be on a case by case basis so I'm not sure a best practices would help.  As with any configuration of a program you either need to bring along that configuration, or re-create it when going to a new machine.

At some point in your development you told the database editor (I'm assuming you are using XNET) that it needs to use a CAN DBC.  You probably pointed it to a file on your disk, and then in your development refered to it by name.  On your new machine, the database editor has no idea that a CAN DBC exists, only that you are trying to refer to it by name, and that name doesn't exist yet.

What I generally do, but right in all situations, is I include the DBC in the LabVIEW project, and then include it in the EXE.  Add your file to the project, then in the application builder you can choose files to always include under the Source Files.  Then your DBC will always be included with your EXE, and Installer if you make one.

Then in startup of my program I will check to see what Aliases exist in XNet using Database Get List.  If my expected name isn't there, then I invoke the Database Add Alias, giving it the path to the DBC, which when in an EXE, will be in a subfolder in the same directory as the EXE.

Other times I have the user specify the full path to the DBC to be used, since a DBC might be updated periodically and the user might not always want to be using the one I included in the EXE.  In these cases I have a path control, and on value change will remove the current alias, add the new one, and restart my software (since sometimes databases already opened won't be updated until the software restarts).

There are loads of other solutions too, like being able to recreate the database on startup of the program, essentially hardcoding parts of the DBC into your source, but this is a bit of a pain and probably isn't needed.

Asside from doing all of this, if your deployment machine does have the Database Editor installed, then you can open it up, and add your DBC to the list of aliases, and then your EXE should work as is.  For a quick fix this might be the easy solution, but down the road you may want to try one of the others mentioned.

[griff32 · Accepted solution]

Thanks Hooovahh,

I did include the DBC in the LabVIEW project, and then include it in the EXE. I also included it in the Installer, but what I didn't do is install NI-XNET on the target PC. I did include NI-XNET  Runtime in the Installer. My issue was on start up I have a dialog to select the database using a right mouse click on the control (Depending on the test, the DBC can be different). 

the right click did bring up The "Browse for Database File..." selection, but it would not execute the file dialog popup after, therefore I had no database selected, and the initialize crashed.

After Installing NI-XNET, the popup worked and I was able to select what ever database I wanted. Bottom line, I will include NI-XNET, not just the Runtime version for all my installers using CAN.

Thanks for the programming help, I am going to try and include your start up of checking to see what Aliases exist in XNet using Database Get List. This seems really smart to make sure  wha DBC file are available .

[Hooovahh]

---

@griff32 wrote:

After Installing NI-XNET, the popup worked and I was able to select what ever database I wanted. Bottom line, I will include NI-XNET, not just the Runtime version for all my installers using CAN..

---

I was not aware of this fact thanks for coming to a resolution.  I'm guessing this popup comes from having the Database Editor tools installed, which seem to only be installed when using the full XNet toolkit, and not just the runtime engine.