Hi,
I upgraded to the 2020 release that was just pushed out, after doing so I'm unable to connect to the SQL spatial database as I would previously. The error is that the credentials are not valid, but I know they are.
What can I do to solve this?
thanks.
Solved! Go to Solution.
Hi,
I upgraded to the 2020 release that was just pushed out, after doing so I'm unable to connect to the SQL spatial database as I would previously. The error is that the credentials are not valid, but I know they are.
What can I do to solve this?
thanks.
Solved! Go to Solution.
Solved by Karsten.Saenger. Go to Solution.
Solved by frosty1_4me. Go to Solution.
I have solved the problem. After attempting many different things, including repairing the install, uninstall and reinstalling 2020 from the Autodesk account downloads page, reviewing security settings on the pc and confirming that the database credentials were correct, the fix was to uninstall 2020 and reinstall 2019 with the 2019 hotfix.
I can say without a doubt that there is an issue with the 2020 version which I will be avoiding now for the foreseeable future.
Immediately upon the uninstall and the reinstallation of version 19.3.32.0 the SQL Spatial database connections worked flawlessly using the same db credentials that failed in the 2020 version.
I have solved the problem. After attempting many different things, including repairing the install, uninstall and reinstalling 2020 from the Autodesk account downloads page, reviewing security settings on the pc and confirming that the database credentials were correct, the fix was to uninstall 2020 and reinstall 2019 with the 2019 hotfix.
I can say without a doubt that there is an issue with the 2020 version which I will be avoiding now for the foreseeable future.
Immediately upon the uninstall and the reinstallation of version 19.3.32.0 the SQL Spatial database connections worked flawlessly using the same db credentials that failed in the 2020 version.
Hi @frosty1_4me ,
I escalated this forum post and topic to the product support and will write you from there to further investigate if there is an issue with InfraWorks 2020.
Any outcome will be place here later.
Regards,
Karsten.
Hi @frosty1_4me ,
I escalated this forum post and topic to the product support and will write you from there to further investigate if there is an issue with InfraWorks 2020.
Any outcome will be place here later.
Regards,
Karsten.
Hi @frosty1_4me ,
I can confirm a database connection issue with InfraWorks 2020 and forwarded this issue to the development team for further investigation.
Will post any updates I get here.
Regards,
Karsten.
Hi @frosty1_4me ,
I can confirm a database connection issue with InfraWorks 2020 and forwarded this issue to the development team for further investigation.
Will post any updates I get here.
Regards,
Karsten.
Hi @frosty1_4me ,
I have re-tested this issue today and the connection to the dabase works now, I don't know why I was not able to connect yesterday.
Could you please make sure you have installed the "ODBC Driver for SQL Server 13"? Maybe it's a driver issue as these drivers are not installed with InfraWorks and need to be installed manually.
Regards,
Karsten.
Hi @frosty1_4me ,
I have re-tested this issue today and the connection to the dabase works now, I don't know why I was not able to connect yesterday.
Could you please make sure you have installed the "ODBC Driver for SQL Server 13"? Maybe it's a driver issue as these drivers are not installed with InfraWorks and need to be installed manually.
Regards,
Karsten.
Hey Karsten,
In fact that is the issue. The required driver is the ODBC Driver for SQL Server 13, whereas my machine had ODBC Driver for SQL Server 11 (version 2014.120.). After installing the driver I am able to connect the database sources within the models once more, as well as add new db sources. Thanks for the response.
Even after the db connection fix, I'm going to revert by to the 2019 version. The performance difference between 2020 and 2019 to load the models is extreme. The model will only render portions of the overall project as you pan around, and if you zoom out to see the entire model it shows it as unloaded. I had chalked this performance issue up to the db connection problem, but that is not the case. A new ticket perhaps? It's quite unusable in this version in the current state.
Hey Karsten,
In fact that is the issue. The required driver is the ODBC Driver for SQL Server 13, whereas my machine had ODBC Driver for SQL Server 11 (version 2014.120.). After installing the driver I am able to connect the database sources within the models once more, as well as add new db sources. Thanks for the response.
Even after the db connection fix, I'm going to revert by to the 2019 version. The performance difference between 2020 and 2019 to load the models is extreme. The model will only render portions of the overall project as you pan around, and if you zoom out to see the entire model it shows it as unloaded. I had chalked this performance issue up to the db connection problem, but that is not the case. A new ticket perhaps? It's quite unusable in this version in the current state.
wow, just saw this after looking for a different issue, but the downgrade to 2019 stuck as the solution.
Now that is embarrassing Autodesk.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
wow, just saw this after looking for a different issue, but the downgrade to 2019 stuck as the solution.
Now that is embarrassing Autodesk.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
@JamesMaeding I believe the solution for this issue is to upgrade the latest ODBC driver which seems to resolve the issue. We will check internally to take care of the ODBC driver issue moving forward.
We would need more information on the performance issue which can be potentially related to other things. @frosty1_4me , we understand this was last year post but if you still have similar issue, please let us know and we will check it out.
@JamesMaeding I believe the solution for this issue is to upgrade the latest ODBC driver which seems to resolve the issue. We will check internally to take care of the ODBC driver issue moving forward.
We would need more information on the performance issue which can be potentially related to other things. @frosty1_4me , we understand this was last year post but if you still have similar issue, please let us know and we will check it out.
shouldn't the install do that automatically?
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
shouldn't the install do that automatically?
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
Absolutely. That's what I meant by taking care of it.
I just want to make sure if there was any other technical reason blocking the team to exclude that with the install package and what can be to avoid a similar issue in the future.
Thanks for pointing this out. Really appreciate the diligent feedback.
Absolutely. That's what I meant by taking care of it.
I just want to make sure if there was any other technical reason blocking the team to exclude that with the install package and what can be to avoid a similar issue in the future.
Thanks for pointing this out. Really appreciate the diligent feedback.
Hi @ramesh_sridharan @JamesMaeding ,
as far as I know the installation of the latest drivers is not done anymore due to licensing issues.So, drivers need to be installed or updated manually.
It's similar to the Java installations/updates that need to be done manually now.
Regards,
Karsten.
Hi @ramesh_sridharan @JamesMaeding ,
as far as I know the installation of the latest drivers is not done anymore due to licensing issues.So, drivers need to be installed or updated manually.
It's similar to the Java installations/updates that need to be done manually now.
Regards,
Karsten.
Is this something everyone should do as standard part of installing new IW versions?
Or is this a special case for those hooking to a particular kind of db that is not the sqlite used to run IW?
I totally get that manually updating a special db driver would be required for the latter case.
I would not expect adesk to manage every kind of special connection engine.
thx
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
Is this something everyone should do as standard part of installing new IW versions?
Or is this a special case for those hooking to a particular kind of db that is not the sqlite used to run IW?
I totally get that manually updating a special db driver would be required for the latter case.
I would not expect adesk to manage every kind of special connection engine.
thx
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
Hi @JamesMaeding ,
such "missing" drivers are only needed if you want to connect to specific databases, mostly if those are in a newer version.
So, no need to care about it for a general InfraWorks installations if you don't plan such connections.
Regards,
Karsten.
Hi @JamesMaeding ,
such "missing" drivers are only needed if you want to connect to specific databases, mostly if those are in a newer version.
So, no need to care about it for a general InfraWorks installations if you don't plan such connections.
Regards,
Karsten.
Can't find what you're looking for? Ask the community or share your knowledge.