FileStore changed-but versioned documents are getting created in old location which is full

Hi,

We had configured 3 filestores and were saving our documents to filestore 1. When filestore 1 got filled up, we changed the default location to Filestore 2. All the newly created documents are going to filestore 2 as expected. But the problem is with the versioned documents.

All the versioned documents are trying to get stored to old filestore which is already full and failing.

Can anything be done to stop this behaviour and make the newly created versioned documents also to save to new FileStore.

Regards,

Rakhi Raveendran

Tagged:

Comments

  • bacham2
    edited February 24, 2017 #2

    With Content Storage Services (CSS) you can define a rule to so that documents stored in filestore 1 should have future version stored in filestore 2. Otherwise, you can implement a TBO that will do the same thing.

  • DCTM_Guru
    edited February 24, 2017 #3

    Strange.  I would open a ticket with support to confirm this behavior.


    In the meantime, you can always use MIGRATE_CONTENT admin method to migrate a batch of documents to new filestore, so that you have some "breathing room" on the old filestore.

  • rakhi_raveendran
    edited February 28, 2017 #4

    Hi Johnny,

    I managed with migrate content API to fix the issue temporarily.

    But with the API with DQL predicate whenever I use a DATE() condition, I get the below error.

    "Bad datatype or value conversion for attribute "DD/MM/YYYY")."

    I tried with single quotes and double quotes but still its throwing the same error.

    I finally went for other filtering options, but I would like to find out how to do the date filtering also.

    Can you please help.

    Regards,

    Rakhi Raveendran

  • DCTM_Guru
    edited February 28, 2017 #5

    What's your DQL predicate for the method/job?

  • rakhi_raveendran
    edited March 1, 2017 #6

    DQL Perdicate-a_storage_type='filestore_01' and r_modify_date>DATE('01/02/2017','dd/mm/yyyy')

    Full API used:

    apply,c,NULL,MIGRATE_CONTENT,TARGET_STORE,S,filestore_02,LOG_FILE,S,/u01/apps/documentum/dba/log/migration1.txt,MAX_MIGRATE_COUNT,S,100000,SYSOBJECT_QUERY,B,F,TYPE_TO_QUERY,S,myCustomType,QUERY,S,a_storage_type='filestore_01' and r_modify_date>DATE('01/02/2017','dd/mm/yyyy'),REMOVE_ORIGINAL,B,T

    I also tried with double quotes. Except date criteria everything else is working fine.

  • DCTM_Guru
    edited March 1, 2017 #7

    FYI - I use full date/time format whenever, I use DATE().  It just seems to work better.  Try this:

    apply,c,NULL,MIGRATE_CONTENT,TARGET_STORE,S,filestore_02,LOG_FILE,S,/u01/apps/documentum/dba/log/migration1.txt,MAX_MIGRATE_COUNT,S,100000,SYSOBJECT_QUERY,B,F,TYPE_TO_QUERY,S,myCustomType,QUERY,S,a_storage_type='filestore_01' and r_modify_date>DATE('01/02/2017 00:00:00','dd/mm/yyyy hh:mi:ss'),REMOVE_ORIGINAL,B,T

  • rakhi_raveendran
    edited March 3, 2017 #8

    Hi Johny,

    I'm still getting the same weird error of Bad Datatype even with time stamp added.

    I doubt if its a problem with Samson from where I'm trying to execute.

    May I know from where are you executing your api s from iapi- or any third party tool ?

    Regards,

    Rakhi Raveendran

  • DCTM_Guru
    edited March 3, 2017 #9

    Have you tried with two single quotes (not double quote)?  This may be escape issue when trying to execute api with single quotes

    One more thing to try is to remove the date format; not required if you the full date/time format I specified.