Genius: "BIM File To Geodatabase" batch first truncates my filenames, then fails because "the layer already exists"

03-03-2021 09:08 AM
New Contributor III

As the title says. The file names aren't exactly outrageously long - about 38 max, which is already shorter than what the tool produces after it truncates them and then prepends e. g. "ElectricalEquipment". Is there a way to fix this nonsense on the user side? Unfortunately there are no options and the tool itself can't be edited(?).

0 Kudos
2 Replies
Esri Contributor

Hello LR2, 

The names are going to be truncated and this is to avoid issues on enterprise database. The feature classes generated by the tool  will be named based on the following rule. 


In this Example I did not modified the dataset name that the tool generated and accepted the default name which is Admin_BLDG_DA_vr12_2020_BIMF  (28 characters).

The resulting feature classes will be name 


For the fails I will need more information. 

* What are you trying to do?  

* Which version of Pro are you using ?

* Which version of Revit are you using as in input ? ( 2017, 2018, 2019, 2020 or 2021) 

* Is this a new database or one that already has data on it ?


0 Kudos
New Contributor III


I'm not writing to an EGDB. The tool shouldn't assume I do and impose irrelevant limits. Furthermore, even if I did this procedure makes no sense. With the most restrictive DBMS (Oracle, 30 chars), it's breaking the limit by prefixing the truncated 28 char filenames with categories up to 20 characters long. Your example is over 30, too. If the tool assumes I use e. g. Postgre, there is no reason to truncate in the first place because even with the longest prefix the original names would stay under the limit (63).

Why it fails is no mystery, the truncating removes so much from the file name(s) that they end up with the same name. For example, MyBuilding_123 and MyBuilding_456 both become MyBuilding if you truncate the last four characters. Then the tool tries to write the second dataset and fails because the name is now the same.

Anyway, I ended up enumerating the files to circumvent this behavior and fixed the result afterwards with FME.

1. Just batch importing a few RVT files into a GDB
2. 2.7.1
3. 2021
4. New

0 Kudos