Home AMX User Forum NetLinx Studio

Relative Path in IRDB Files

Hi All,

I've got a problem with My Netlinx Studio 3.1.0.374.

If I include an IR from an IR Database in my project, Netlix dosent save the relative path correctly so when I put the project on my laptop to install the program in the client home I should delete and reiport all the IR files.

Does your Netlix have the same probem?

Thanks

Comments

  • DHawthorneDHawthorne Posts: 4,584
    Any project created more than about a year ago has a similar issue for me. If I used the database, it can't find the IR file when re-opened later. I got so disgusted with it, I just started exporting devices to a stand-alone file and scrapping the database altogether.
  • DHawthorne wrote: »
    I just started exporting devices to a stand-alone file and scrapping the database altogether.

    It's not a solution! there is any way to signal thi sproblem to AMX that will solve it?

    They must solve the compatibility prolem of IREdit and the other AMX application and Win 7, and this culd be an occasion to do an important upgrade of all AMX application.
  • the8thstthe8thst Posts: 470
    I export devices and use individual IR files as well.

    This method allows me to have all of the IR files for every job within the job folder. That means any installer in the company is able to load/view/change IR commands in a job without worrying about whether we all of the same database or not.

    It is really nice when an installer can change devices and tvs for different models or brands without involving me in the process. The just have to open the existing IR file and make sure the mapping of the new device's IR file is the same.
  • I not Argree about that, I've just turned on the IR database system in my company because of in past we had all single files, but we had every day problems about duplicate files and updating.

    Anyway I think that it's a bug of Netlinx and AMX SHOULD correct it to make sure that his installers can work better.
  • AuserAuser Posts: 506
    the8thst wrote: »
    I export devices and use individual IR files as well.

    It's easier (and potentially requires less storage space) to check IRL's into a code versioning system without conflict when different users are working on them simultaneously too.
    Darkman88 wrote: »
    I not Argree about that, I've just turned on the IR database system in my company because of in past we had all single files, but we had every day problems about duplicate files and updating.

    Anyway I think that it's a bug of Netlinx and AMX SHOULD correct it to make sure that his installers can work better.

    I don't disagree that it's a bug which needs to be fixed, but it in the meantime it sounds to me like there may be a cause for investigating a code versioning system like Subversion at your workplace to prevent the problems you've mentioned with conflicting changes between multiple users.

    I would suggest taking a look at VisualSVN as a server package and TortoiseSVN as a front end on the machines used to edit/update the files. Both are free and are designed to coordinate changes to files across multiple users and ensure there's only a single copy of the files being worked on. These systems have the added benefit of tracking changes to files over time, too, so you can roll back to an earlier copy if something gets broken inadvertently.

    Just a thought.
  • Auser wrote: »
    I would suggest taking a look at VisualSVN as a server package and TortoiseSVN as a front end on the machines used to edit/update the files. Both are free and are designed to coordinate changes to files across multiple users and ensure there's only a single copy of the files being worked on. These systems have the added benefit of tracking changes to files over time, too, so you can roll back to an earlier copy if something gets broken inadvertently.

    Just a thought.

    We have actually using Tortoise SVN with an SVN server on our servers.

    We have tought that an IR DataBase was the best method to archive all the IR that we clone.

    Anyway Thanks a lot for the suggestion.

    I actually think that AMX should be informed about the BUG and Shold fix it ASAP.
  • AuserAuser Posts: 506
    Darkman88 wrote: »
    We have actually using Tortoise SVN with an SVN server on our servers.

    Good to hear, sounds like you're ahead of the curve.
  • the8thstthe8thst Posts: 470
    SVN is on my short list to setup for next year. I will be overhauling our company servers, so it seemed like a good time to implement it.

    Does anyone have any good training documents to give installers? They will have to be able to check out files to load onto systems at jobsites and I know they will have a lot of questions.

    Also, will SVN servers work with TPD4 and IRL files? If not, what are you using for version control of TP files?
  • PhreaKPhreaK Posts: 966
    SVN will play nice with (just about) anything. With files like the tp and ir files they will need to be set up to force a lock before editing as they can not be merged if multiple people work on them simultaneously. For info on how to set this up and training guff for the installers check out the [url=xhttp://tortoisesvn.net/docs/release/TortoiseSVN_en/index.html]Tortoise SVN docs[/url]. It's an awesome resource and has plenty of info on general version control concepts as well.

    If you've regulary got people making modifications to versioned files in locations where they may not have a network connection to your SVN server you may want to look at a distributed version control system, such as Git, as this will allow them to check in changes locally and give a bit more granularity to the audit trail.
  • the8thstthe8thst Posts: 470
    PhreaK wrote: »
    SVN will play nice with (just about) anything. With files like the tp and ir files they will need to be set up to force a lock before editing as they can not be merged if multiple people work on them simultaneously. For info on how to set this up and training guff for the installers check out the [url=xhttp://tortoisesvn.net/docs/release/TortoiseSVN_en/index.html]Tortoise SVN docs[/url]. It's an awesome resource and has plenty of info on general version control concepts as well.

    If you've regulary got people making modifications to versioned files in locations where they may not have a network connection to your SVN server you may want to look at a distributed version control system, such as Git, as this will allow them to check in changes locally and give a bit more granularity to the audit trail.

    Thanks for the info.

    My plan is to use Tortoise on the laptops (installers wont be committing changes, just checking out and loading to the system on site) and either running the SVN server on our windows server at the office or on a NAS drive (Netgear NV+ or Synology DS411j).

    I will also look into git before I make any permanent process changes.
  • We actually use this combination:

    Tortoise SVN on any PC that will work with the project (Graphic,Code) and Collabnet Subversion server on the windows server (http://www.open.collab.net/downloads/subversion/).

    For the installation you can search the Svn Book (when you install the collabnet SVN server you can find it in the start menu) that will explain how to install and configurate the svn server and how SVN work.

    It's useful for you to build up some authentication policy:
    For Example we use this authentication policy:
    The developer can commit in all the repository (Graphic and code).
    The installers have got an read only access to the repository.
    The developers that non follow a project havent got access to the repo.

    I Hope that this help
    Bye
Sign In or Register to comment.