Sorry to beat a dying horse: Local Paths Issue

[paulourada]

I *have* done a search on this issue, and I think I have a different problem than what has been discussed in the last couple of years.  So, please bear with me.

Yes, we do have a database which has a half dozen or so different paths to generated code.  Yes, I do know how to hunt them down and fix them with a local path.  But this is where the problem comes up, that I haven't seen any solutions to in previous posts.  

After I apply the local path, I don't see the local path macro show up in the Generate Code dialog box.  The XML file shows the %MyPath% macro in the code generation path, but when I look in the Code Generation dialog box it shows it as if it were expanded: "C:\Some\Path\To\This\Darn\File.h".  It should look like: "%MyPath%\To\This\Darn\File.h"

If I am to have any hope of getting the rest of my users to use Local Paths, I've got to fix this.

Any Ideas?

Thanks,

Paul Ourada
Principal Software Engineer
Covidien, Energy-Based Devices

[Paolo F Cantoni]

Hi Paul,

When we've had the same problem, we found there was no real alternative to direct surgery in the DB.

Fortunately it pretty easy and straight forward.  Just check the t_object and t_package tables and you'll soon see what needs to be done...  

Once you've found the values that you're missing (that is, don't have maps for) you can manage them via the dialogs by forcing the values and then remapping them - if you don't want to fix things directly i the DB.

HTH,
Paolo

[paulourada]

Hi Paolo -

Thanks for the quick response.  While I basically understand what it is that you are telling me, and I do have the general idea that the *.eap files are MS databases, I am an embedded systems developer, and not a database guy.  So, I don't exactly know what tool to use to manually examine the database.  We do have some copies of Visual Studio, is there a database spelunker in there I can use?

Also, this brings up another question.  We use Synergy as a version control tool for the XML files.  The EAP file is basically empty, but for a few package stubs.  The idea was that we wouldn't have to keep a fully populated, and fairly enormous EAP file in the version control system.  We'd just use the XML files to keep the state of the individual packages and use Get All Latest to lock and/or import them.  

So, is this surgery you speak of something that is going to have to be repeated every time someone starts out w/a fresh copy of the EAP file?  Or should we consider abandoning the idea of having an essentially empty copy of the EAP file and start keeping the fully updated version in Synergy as well?

Thanks,

Paul

[Paolo F Cantoni]

Hi Paolo -

Thanks for the quick response.  While I basically understand what it is that you are telling me, and I do have the general idea that the *.eap files are MS databases, I am an embedded systems developer, and not a database guy.  So, I don't exactly know what tool to use to manually examine the database.  We do have some copies of Visual Studio, is there a database spelunker in there I can use?

Also, this brings up another question.  We use Synergy as a version control tool for the XML files.  The EAP file is basically empty, but for a few package stubs.  The idea was that we wouldn't have to keep a fully populated, and fairly enormous EAP file in the version control system.  We'd just use the XML files to keep the state of the individual packages and use Get All Latest to lock and/or import them.  

So, is this surgery you speak of something that is going to have to be repeated every time someone starts out w/a fresh copy of the EAP file?  Or should we consider abandoning the idea of having an essentially empty copy of the EAP file and start keeping the fully updated version in Synergy as well?

Thanks,

Paul

Use Access to view the database.  Just open the .EAP file.

From memory, the columns are GenFile in t_object and CodePath in t_package.

If you already have .XML files, you should be able to globally search and replace with a decent editor.  Then reimport.

The point is, each user has to have the set of local path variables defined for the thing to work properly.   Once that's the case, EA figures it all out for you pretty transparently.

HTH,
Paolo