11 Replies Latest reply on Jun 8, 2010 3:50 PM by Raymond Pearson

    file naming convention

    Mark Larson
      if you were coming up with a file name convention, how many characters and what format would you use? would you include data seperators? (XXXX-XXXX-XXXX as opposed to XXXXXXXXXXXX) and if so, which one(s)? Would you use all numbers, letters, or a combination?
        • Re: file naming convention
          Jeff Sweeney

          If I was Earth Czar and had total control over everything, my file names would be simply numbers.


          Mixing alpha and numbers can be confusing. (stupid "I" and "O" can cause confusion.)


          My Earth Czar numbers wouldn't have any meaning, just the next available number when I create the file. Though I appreciate dashes because it makes numbers easier to read, they add a level of complexity when it comes to programming so I'd make my loyal subjects read numbers without dashes.


          I wouldn't even have leading zeros. Mt first file would be "1" and my tenth file would be "10".


          But so far I am just Jeff, so I understand there have to be compromises, and with a PDM system the file naming convention really isn't that big of a deal - you can live with almost anything those marketing guys come up with.

            • Re: file naming convention
              Mark Larson

              "you can live with almost anything those marketing guys come up with"


              true, especially if you get paid by the hour (ah, if only!)


              what brought this on is a filename with 59 characters,

              glad I didn't originally post that since the max size I have encountered is now 74

                • Re: file naming convention
                  Jeff Sweeney
                  74 characters pretty long. Remember many applications will only accept full file names (including their paths) to be less than 255 characters, you'll need to ensure your local cache is very shallow in your directory structure or you'll go over that limit pretty easily.
                    • Re: file naming convention
                      Geoffrey Leonard

                      The system you implement must be data base friendly. Once you start numbering in a certain way it's becomes difficult to change a year or two afterwards.


                      This is the system we use 0001, where 0001 means this is the first project we've done.




                      You could attach the year example, 2010_0001.


                      Then you could name your assembly '2010_0001 Machine Tool' and the parts 2010_0001_01 and so on.


                      Hope this helps.

                • Re: file naming convention
                  Richie Yosten

                  I would look at a spec for the industry you are providing data for.  In the aircraft industry we follow manufacturer, customer or industry standards for file naming conventions.


                  There's also another way of thinking...

                  Many smart people have written that the more meaning you place in a numbering scheme the more likely it is to fail you in the future.  Think about all of the changes a company can go through over the years.  When a place in the character string or a sequence of characters has to mean something it may not work with some future project

                  ...plus there is the subject of meta data.  If you are using PDM you have little reason to assign any meaning to a numbering scheme.  You'll always be able to find what you are looking for if the data cards are populated.  This idea is not always realistic...but it does make sense.

                    • Re: file naming convention
                      Mark Larson

                      the big problem with the present scheme is that with a mongo number of characters, filenames are often entered incorrectly.

                      another problem I see is in characters used to give order that only seem to foul things up

                      do I use a -, _, a space, or nothing at all?

                      do I call it Bracket-left-blue, blue left bracket, or  left blue bracket

                      the consequence is that there are multiple part numbers for the same part, and we order more even though the stockroom has many, they are just "numbered" something else

                    • Re: file naming convention

                      I like non-significant part numbers, 5-8 characters long.  These types of numbers force people to look at BOM or ERP data instead of trying to commit things to Tribal Knowledge.

                      • Re: file naming convention
                        Rich Schneider

                        Project number (the common four digits for any project used to be refered to as "Brass Tag" numbers) first, then three digit numbers after a dash (x00 being the assembly, x01, the first detail,, x02 second detail, etc.).  I lean towards adding detail name text after that.  If you have to renumber any files it really helps having a description to keep things straight. All jobs for year 2010 would be under the 2010 Jobs folder, after a few years it's pretty straightforward to see where the legacy files can be stripped off the server into archive.  Some would argue PDM negates most of what I said, but obviously this depends on your line of business and company needs.

                          • Re: file naming convention
                            Raymond Pearson

                            I agree with all of you...


                            A Part Number should be simple next number, no leading zero's.

                            The file name should be the part number in most cases, unless the file does not have a part number (a child of a purchased assembly).

                            Any other coding should be at the field/property level. Then you can search in any combination you like.

                            If needed for programing or other, you can build a configuration string from the spec's filled out.

                            Avoid "where used" codes. Anything can be used anywhere always.