Forced upgrade to ArcGIS Enterprise 11.2?

[TomGeo]

Since we updated to ArcGIS Pro 3.2 we have issues with our Enterprise databases. One of the issues is, that we cannot write to them...

New data types such as 'date only', object ids are now 64 bit instead of 32 bit, etc. 

With a test database I luckily had laying around I attempted an upgrade from 11.0.0.3.9 to 11.2.0.49743. Not that I could have selected any lower database version!

The upgrade went well and now I am able to write data again to this database! However, the next that is throwing stones in my way is sharing the data as a web layer to our Enterprise portal.
When analysing the layer I am getting the following error:

We actually never had the intention to upgrade our portal (10.9.1) to 11.2, since 11.2 is a short-term support release, while 11.1 is a long-term support release.

Could it be that we are forced to upgrade to a short-term support release, simply because ArcGIS Pro 3.2 does not support the long-term support release? It kind of makes the whole thing ridiculous.

[LeoDCG]

One suggestion from the help states

"In ArcGIS Pro 3.2 and later, new field types to support date, time, and big integer values are available. When query layers on unregistered datasets or text files are added to a map in ArcGIS Pro 3.2, these fields may be assigned to the new field types, which are unavailable in earlier releases. To opt out of using new field types for query layers and text files, check the Use field types that are compatible with ArcGIS Pro 3.1 and earlier releases when adding query layers and text files option."

[TomGeo]

Yes, I am aware of this possibility, and as the help already states "...for query layers and text files,...". This does not help in any way to overcome the issue that ArcGIS Pro 3.2 seems to force our hand updating our Enterprise Portal to a version we have no intention to.

I agree with @RyanUthoff that this seems to be a poor design choice. The way this implementation effects the wider ArcGIS environment causes a lot of issues, and that there is no way to circumvent these data type changes is really bad.
"In ArcGIS Pro 3.2 and later, new field types to support date, time, and big integer values are available...." -> available suggest that I do not have to bite the bullet and can refrain from using them! For the majority of cases that's not possible. Forcing the use of database versions incompatible with the latest long-term support version of ArcGIS Enterprise is equally bad!

[RyanUthoff]

Yep, we've encountered this as well. Unfortunately, the way these new field types were implemented in 3.2 was a poor design choice and has caused us lots of issues. We have to completely rework our Python scripts to make query layers out of all of our tables/views before registering them, because that's the only way the register with geodatabase tool will honor the new "compatibility mode."

See this thread. https://community.esri.com/t5/geodatabase-questions/high-precision-date-field-issue-when-registering...

[Laura]

I am having this same error message. I did not intend to upgrade my Portal so soon and now this is causing issues within the organization. 

[VentsislavStanchev]

Hello, 

currently have two verified options to resolute this problem.

1. Upgrade ArcGIS Enterprise to 11.2 

2. Downgrade ArcGIS pro to 3.1 with latest patch

[AndyIngall]

Hi

I came across this issue yesterday, I have found that i am still able to publish web layers to the portal if I use data directly from the database, if I try and do it from a view, or from a feature class with a layer file attached it doesn't work.

I am using ArcGIS Pro 3.2 with Portal 10.8.1, which is no where near ideal, but due to the portal security patch error have not been able to upgrade.

I totally understand that GIS move on, but this is not a great situation.

Andy

[WarrenMedernach]

So it's not just me... this is absolutely insane!

After much trial and error I did manage to figure out that changing a Query Layer to use the actual SQL and not a View seemed to allow me to publish the layer from 3.1 for data that is not participating in the geodatabase.  But now I cannot publish layers from a geodatabase with 3.1 either?!?!

It looks like I need to resort to using 3.1 and publishing geodatabase feature classes as Query Layers ¯\_(ツ)_/¯.  Way to go E$RI.

I had no intention of upgrading our Portal to 11.2 either, but this now seems like a requirement?!?!