I recently use Import-PWDocuments to import huge folders (275000 files, about 700 Gb)
It worked quite well but i had 3 different issues,
WARNING: Error 56049 creating 'xxx.pdf' in \x\x\
WARNING: Error 50000 creating
WARNING: Error 58258 creating
I have lot of folder in windows with path > 255 car but Import-PWDocuments seems to deal with this correctly
About 120 files where missing pretty much everywhere , and different king of files (jpg, pdf, ..) without any errors messages
perhaps -verbose helped me to have more informations but with more than 275000 files it will be unreadable
Searching the ProjectWise SDK header files, I see these for your error codes:
#define AAERR_DYNSQL_DB_COMMUNICATION_FAILURE 56049
#define AAERR_NOT_FOUND 50000
#define AAERR_DMS_ERR_TOO_LONG_FILE_NAME 58258
You might want to check the log files on the Integration server for the Integration service, perhaps they might give you a clue.
You might consider targeting a smaller number of files, particularly where you seem to be missing files, use -verbose, and see what turns up.
Dan WilliamsSolution ConsultantBentley Systems, IncorporatedPortland, OR, USA (Pacific Time UTC-08:00)
Thanks for your answer
i'll try verbose on another import because the data are now in production
Too many logs in integration service, i can't find anything relevant
Do you know the longest path autorized in projectwise ? ant the longest filename ?
When you say "longest filename", that may depend upon what you mean by "filename".
My understanding is that in Windows the file's name is limited to 255 characters and the path length (including the file's name) is limited to 260 characters. There is some potential workarounds for longer paths in Windows 10, but I doubt if they have been tested with ProjectWise.
In ProjectWise, "paths" and a file name size are a bit different. There is "no limit" on document paths in ProjectWise other than how long you are willing to wait for them to be built via queries to the database or having to browse (navigate) very long paths. I'm not aware of anyone having slow displays or searches in ProjectWise Explorer because of very long "paths" in ProjectWise.
As for the longest file name, well that is limited to the size of the column o_filename in the table dms_doc which is nvarchar(127) in SQL Server which can potentially be a problem if you have actual file names longer than 127 characters.
Now if you think changing the size of this column in the database will allow you to have longer filenames, don't do it for at least three reasons!!!
1) Modifications of the database schema are not supported (other than what Bentley Support suggests because of specific problems, and these tend to be indexes, not changes to database tables/columns).
2) ProjectWise will ignore the "extra" size - my guess is that the memory buffers for filename are "hard coded" to 127.
3) Unknown "side effects".
I suspect that your "problems" are likely due to some file paths are longer than what Windows supports. It is possible to create longer than supported paths in Windows, but then accessing them becomes a problem depending upon how they are accessed. I would suggest shortening your paths in Windows so that no path to a file, including the file's name is longer than 260 characters. You should also check to make sure that all the file names (not including the path) are 127 characters or less.
I have also noticed that there appears to be a limit to the length of an individual folder name (approx. 62 characters).
Can you confirm if that's the case?
63 is the max for folder names. Those values are stored in dms_proj.o_projectname which is nvarchar(63).
Dave, 63 max is correct.
FWIW, some folks use the description field for longer folder "names" (127 characters) and then use a shorter (real) name. Keep in mind that folder names (o_projectname) must be unique in the context of a parent folder while folder descriptions do not need to be unique. But if you are using the folder descriptions as the folder "name", then you need to be careful not to create "duplicates". This really isn't much of a problem since you still need to specify a unique (real) folder name.