Error occured during deployment: Input string was not in correct format

[Rasenkantenstein]

Describe the bug
When deploying an error message appears:

To Reproduce
Steps to reproduce the behavior:

*click on deploy and the error occurs.

Expected behavior
In 2.13.2 (portable) the error for the same model does not appear.

Observed behavior
A clear and concise description of what happened. Include any error messages or stack traces if possible. Also, feel free to add screenshots or recordings showing the problem.

Application specifics

• Tabular Editor version: 2.14.0
• Semantic Engine used: SSAS 2019
• Model Compatibility Level: 1500

[otykier]

I'm not able to reproduce this. A couple of things to try:

• Copy the "TMSL Script" from the last step of the deployment wizard, and execute it using SSMS - what error message do you get?
• Have you tried performing the deployment with 2.13.2 after you first saw this error? If so, does that still succeed?

To investigate further, is it possible that you could send me the Model.bim file or a .zip of the model folder structure? Thanks!

[dmgdotnet]

I had the same issue but didn't get a chance to look into it, rolling back to 2.13 made the error go away. When I get a chance I will do some more testing with 2.14 and see if I can supply more info.

[helgews]

As I encountered the same issue today, I tried what @otykier suggested.

• Encounter the same error as @dmgdotnet when trying to deploy from TE 2.14 over/into existing instance of Azure Analysis services 1500 model.
• Go back and copy the TMSL-script, connect to Azure AS in SSMS, new XMLA-query, paste script, execute
• No errors.. "Query executed successfully."

[otykier]

If someone is able to provide a Model.bim, zip of the model folder structure, or the TMSL-script that reproduces this behaviour, that would be really helpful - thanks!

[otykier]

I think this is an issue on the Microsoft side. When I tried to execute the TMSL using SSMS against AAS, I now get the same error as observed in Tabular Editor. This was on a westeurope instance of AAS, which seems to have been updated recently. If I try to deploy the same model to a local instance of SQL Server 2017 AS, I get no error in neither Tabular Editor or SSMS.

In other words, for those of you who are using AAS, you may also start to see this issue shortly, even with previous versions of Tabular Editor, as Microsoft is updating the instances worldwide.

I'm reaching out to Microsoft immediately to make them aware of this!

[otykier]

Update: Apparently, this issue affects TMSL refresh operations as well: https://stackoverflow.com/questions/66009598/aas-processing-through-linked-server-json-ddl-request-input-string-was-on-in - this confirms my suspicion that it's not related to Tabular Editor at all. Leaving this thread open to post updates when I hear back from Microsoft.

[Rasenkantenstein]

Hi Daniel. I can post my bim file tomorrow as a private message. However I am deploying to onprem SSAS 2019. when opening tabular editor 2.13.2 as a portable parallel to the installed version 2.14 the very same model is deployable with the older version but not with the new version.

[helgews]

Agree on the update. The issue may be in the Microsoft/service area. At some point today, I had a slightly different "Input string ...." error message. This went away when I restartet the AS service in Azure Portal, at then I could deploy a (new) model again.

[otykier]

@Rasenkantenstein no need to post the bim file. The issue is most likely with TOM version 19.16.0 which version 2.14 of Tabular Editor uses. This version of TOM was recently deployed (by Microsoft) to Azure Analysis Services in western europe, which explains the issues that some users are seeing when deploying to AAS regardless of what version of Tabular Editor they're using. So for on-premise SQL users, this means that you will have to use the previous version of Tabular Editor, until Microsoft fixes the TOM.

[numisi]

We started having this issue today deploying from Tabular Editor to Azure Analysis Services, also executing TMSL refresh commands via .Net (Microsoft.AnalysisServices.NetCore.retail.amd64) and in SSMS executing XMLA commands.

After several attempts and removing Tables from the Model we could limit the problem to some Metrics (that never had issues) and specifically to the Translated Names properties that had "English (United States) -- (en-US)" values filled (0 empty, 0 translated, 1 default).

After removing all the strings from this properties we started to deploy/refresh without errors.

[otykier]

Update: Microsoft are aware and are working on fixing this. No timeline yet.

Some more context:

Hey folks, there’s a regression related to special characters in object name references (e.g. Perspective table/column names that use certain special characters). You may be able to workaround this by deleting the DB, removing special characters like '.', '[', ']', ':', '$' and redeploying, but we’re still validating the details of the problem and will hopefully rollback the regression soon…

[dmgdotnet]

Update: Microsoft are aware and are working on fixing this. No timeline yet.

Some more context:

Hey folks, there’s a regression related to special characters in object name references (e.g. Perspective table/column names that use certain special characters). You may be able to workaround this by deleting the DB, removing special characters like '.', '[', ']', ':', '$' and redeploying, but we’re still validating the details of the problem and will hopefully rollback the regression soon…

Thanks Daniel!

[bialysz]

Hi guys! Any news here? I can't find any official statement from Microsoft about this issue.

[otykier]

@bialysz There's no official statement, I guess since this is only impacting customers in some regions (not all AAS instances worldwide are upgraded simultaneously). I believe they are rolling back the upgrade as we speak. Some users have reported that pausing and then resuming the instance solved the problem. I would be very surprised if it's not fixed by next week.

[bialysz]

@otykier Thanks, tried that with my AAS's without success. I'll just try to do all the work manually.

[helgews]

We are back in it now, able to deploy new models and overwrite/update existing models. We had to delete and deploy one fresh to get it going, however..

[otykier]

Thanks for the update @helgews - are you able to deploy using version 2.14.0 of Tabular Editor, or did you have to roll back to a previous version?

[helgews]

I am using 2.14.0

[jgoleson]

We were getting this error when doing AAS deployments. I had a support ticket open with MSFT and this is the latest news they gave me:

The Dev team has made the decision to go ahead and rollback the previous release deployed in Jan 29/30th which caused the regression instead of applying the fix at this point in time. The deployment for the rollback has begun, we will update you once we have a firm timeline on it, I expect it would take the weekend roughly.

After they sent this, we tried deployments again and were successful.

[otykier]

Is anyone still experiencing this issue as of today, using Tabular Editor 2.14.0?

[Rasenkantenstein]

@otykier Yes. I still have the problem when deploying to my On-Premise-Model.

[dmgdotnet]

I still have the issue too but haven't done any updates yet to SQL instance or otherwise

[otykier]

@Rasenkantenstein could you please try to see if newly released version 2.14.1 solves this issue against your on-premise model? The TOM has been updated to 19.16.3 which should contain the fix that Microsoft applied to their Azure AS instances.

[Rasenkantenstein]

I still get the same error. I'll send you a model tomorrow if you need it?

[helgews]

You get the same error when trying to deploy as a new model? Also when copying the script and running it in ssms?

[Rasenkantenstein]

@helgews you're right. For an empty database it works fine. Also copying the script and pasting it in SMSS works fine. Thank you for the advice. So all I need to do is wait for the patch to reach SSAS onprem and I'll be able to deploy directly from Tabular Editor again?

[helgews]

@Rasenkantenstein In our case, we deleted the old model and deployed new with the same name. Since that, we have been updating directly from TE many times and by different developers.

It gave a downtime of 30 minutes in hour case, because we had to fill up all the tables again. But we have not had issues since.

So, today was releaseday. And it turns out, we cant deploy over existing model in prod either :) When looking at the script running, I see it repeats this pattern over and over again.

<Discover xmlns="urn:schemas-microsoft-com:xml-analysis"> <RequestType>TMSCHEMA_KPIS</RequestType> <Restrictions> <RestrictionList> <DatabaseName>SSAS_SINTEF</DatabaseName> </RestrictionList> </Restrictions> <Properties> <PropertyList/> </Properties> </Discover>

The end result is not "Input string was not in correct format" this time. But " An internal error has occured..".

I'll have to wait untill after work hours and do a delete and new deploy then.

[jamhos]

@helgews we're having the same issue. Fortunately the model most consistently having the "An internal error has occurred" error on deploy is quite small so we've just been deleting and redeploying (or, deploying under a temp name, then doing a name switch once it's all processed).

[otykier]

I just posted release2.14.2, which uses an updated version of the TOM. Could you please check to see if this is still an issue with this release? Also, those of you having issues, which build number of Analysis Services are you deploying against?

[jamhos]

Thanks very much @otykier, that seems to have fixed the issue for us! AS 15.0.34.29.

[jamhos]

And just FYI on the above, we discovered that even with the "an internal error has occurred" error, the deploy did still actually work, so we didn't need to delete / redeploy.

[otykier]

@Rasenkantenstein do you still see this issue with the newest version of TE? If not, can we close this thread? Thanks!

[dmgdotnet]

I no longer have the issue either, did a delete and redeploy to be safe but no issues since then.

Thanks @otykier !

[Rasenkantenstein]

:-) Thank you so much for the effort!