#12! getting added in xml (Save as Script of sql restore), is not legal for a JDOM character content: 0x0012 is not a legal XML character

@Mike Struening RETIRED 
Sorry for the late response on this thread.

Here is the update i received from support on this.

======================================================================

Can the customer try to use CommServDBQuery activity in which you pass the xml in as parameter and perform a SQLXML query on it to retrieve the value?

=======================================================================

This is the update that I received from support, and this works if the user who initiates the script is given with the required permissions.

this thread can be resolved.

Thanks!  If you hear anything, let me know (or I’ll update if I do first).

See ya later, @alligator !

I had opened a ticket with support for this

yet to hear from Dev team

@Mike Struening  221027-389 is the case ID# for your reference.

@alligator I do not have good news. First pipe char in <device> key is crucial when restoring DB to different loaction (drive/folder). Without it I got 

Query Result tMicrosoft.SqlServer.Management.Common.ExecutionFailureException:Directory lookup for the file "H:\DATA\IKB.mdf" failed with the operating system error 3(The system cannot find the path specified.). File 'IKB_UAT' cannot be restored to 'H:\DATA\IKB.mdf'. Use WITH MOVE to identify a valid location for the file. Directory lookup for the file "G:\LOG\IKB_1.LDF" failed with the operating system error 3(The system cannot find the path specified.). File 'IKB_UAT_log' cannot be restored to 'G:\LOG\IKB_1.LDF'. Use WITH MOVE to identify a valid location for the file. Problems were identified while planning for the RESTORE statement. Previous messages provide details. RESTORE DATABASE is terminating abnormally. An exception occurred while executing a Transact-SQL statement or batch.]. Source: restoresrv02v, Process: SQLiDA

But when the source and destination locations are the same WF works.

@Roman sure, let me also try and i will update here 

Thank you :)

@alligator I do not know. I was looking for solution all day long and I will check my workflows tomorrow (I’m from Poland) but this is very promising. My test workflow works like a charm now and database restored properly.

Check it and post the results. I will give feedback tomorrow.

@Roman i will check this by removing the “|” from the device information

are you saying #12! is not the problem here for this error?

@alligator

Try to remove first | char from all <device> lines. I had similar problem and it looks very promising.

I had problem with Java:

Stringn] params = new Stringn2];
paramsm0] = "|SSISDB|#12!SSISDB|#12!data|#12!D:\\DATA\\SSISDB.mdf|#12!D:\\Program Files\\Microsoft SQL Server\\MSSQL12.MSSQLSERVER\\MSSQL\\DATA\\SSISDB.mdf";
paramsm1] = "|SSISDB|#12!SSISDB|#12!log|#12!E:\\LOG\\SSISDB.ldf|#12!D:\\Program Files\\Microsoft SQL Server\\MSSQL12.MSSQLSERVER\\MSSQL\\DATA\\SSISDB.ldf";
return params;

I got error:

" is not legal for a JDOM character content: 0x0012 is not a legal XML character.

<device>:

<device>SSISDBSSISDBdataD:\DATA\SSISDB.mdfD:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\SSISDB.mdf</device>
<device>SSISDBSSISDBlogE:\LOG\SSISDB.ldfD:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\SSISDB.ldf</device>

Then I deleted “|”:

String"] params = new Stringw2];
params/0] = "SSISDB|#12!SSISDB|#12!data|#12!D:\\DATA\\SSISDB.mdf|#12!D:\\Program Files\\Microsoft SQL Server\\MSSQL12.MSSQLSERVER\\MSSQL\\DATA\\SSISDB.mdf";
params/1] = "SSISDB|#12!SSISDB|#12!log|#12!E:\\LOG\\SSISDB.ldf|#12!D:\\Program Files\\Microsoft SQL Server\\MSSQL12.MSSQLSERVER\\MSSQL\\DATA\\SSISDB.ldf";
return params;

and got this Workflow working.

<device>:

<device>SSISDB|#12!SSISDB|#12!data|#12!D:\DATA\SSISDB.mdf|#12!D:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\SSISDB.mdf</device>
<device>SSISDB|#12!SSISDB|#12!log|#12!E:\LOG\SSISDB.ldf|#12!D:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\SSISDB.ldf</device>


But I have to verify all of my Workflows to be sure.

@alligator , apologies for the delayed reply.

If you are already patched up to that level, this is likely something else.

I would suggest opening a support case and sharing the number here so I can track it accordingly.

@Mike Struening thanks for the response

we are already at 11.28.19

@alligator , thanks for the post!  I have found a form ID (5186) for this issue.

Can you confirm the version of your Commserve?

I see it is in:

11.24.57

11.26.32

11.28.11

Thanks!