We have multiple users getting this error on multiple workbook files (see below). We have never seen this error before today. We're running TDP 188.8.131.52. Database is SQL Server 2016.
On the surface, seems to be a datatype incompatibility issue... Not sure how INT32 differs from a number or integer datatype.
Please give specifics on steps needed to reproduce, as this would be helpful for Quest Support and Dev teams.
Gary, I think I found the problem. There is a Windows 10 update KB 4565633 that appears to be causing this issue. I had 2 users with this issue that had this update installed last night and after uninstalling the update TDP is working fine again. Other users that don’t have this update installed are doing fine. Can you guys research this on your end to see if you can replicate the issue? I’m sure this update will get automatically installed again and will be causing the same error for us.
Red-lined to Engineering... they will try to reproduce and confirm, thanks for posting here so others might be warned>>>
Thanks Gary. Any updates from Engineering yet? KB4565633 was reinstalled on our systems overnight so we had to uninstall again this morning.
Still taking a look at this one Steve...
can you please send us some of you workbook file? Are you able to reproduce it also with the new files? I have this updated installed on my machine but I am able to work with my WB without the issue.
I had the same issue with my computer with a .NET framework update on 7/15/2020.
I am using Toad 4.3 as a budget analyst at the University of Alaska.
I am working from home and after installing Microsoft update KB4565503 & KB4565627 on my personal computer, I started having issues running some queries, but not all queries. The error messages varied depending on which query I was trying to open. Also, I would even have trouble with some queries that I had just created. If I added a table to the query with all fields and saved, I could reopen. However, if I added a filter then I was unable to reopen the query.
The main way I knew that the issue was mine and not related to the query is because I was able to open the queries previously and my supervisor could still open the queries.
My machine is using the 64 bit Microsoft Windows 10 Home edition Version 2004 and I connect via VPN to our network in order to access the TOAD license and many of the queries I use are on the network shared drive.
I uninstalled the .NET framework update (KB4565627) and everything worked fine. Note: I did NOT uninstall the Cumulative Windows 10 update.
I tried to upload a file with screenshots (error messages and windows update notice), but new users don't have upload privileges.
Let me know if I can be of further assistance.
This may help to reproduce the issue or find the location of the code being affected. I'm running into the same issue (Toad 4.3). It seems to be related to the code/calls with the local where clause. I found if I used the Visualize Query option on the SQL of a query that failed to open, and re-saved the file I would not run into the error. All of the queries local where clauses got shifted to a Global where clause. With testing I found I could save and re-open queries that were only using global where clauses, but if I save a query with a local where clause the file open will fail with the error.
Quest: re-reading all of the above, I don't know if anyone made this clear to quest support. This error doesn't happen when you run a query. It happens when you load an existing toad query from a file. If you were to re-build the query from scratch it would run fine. I documented my experience in this post:
we are still investigating the issue. Can somebody of you please send me ExceptionTrace.log from this location?
C:\Users\ YOURUSER \AppData\Roaming\Quest Software\Toad Data Point 5.1
you can upload it there or please use my email directly: firstname.lastname@example.org
Hi Filip, see attached exceptiontrace.log file.
ExceptionTrace.log (90.4 KB)
File as requested.
ExceptionTrace.log (173.6 KB)
I had the same problem with latest TDP 5.1.7 software and PostgreSQL30 or PostgreSQL ANSI drivers. Uninstalling KB 4565633 corrected the problem for me as well.
we found source of this issue. Workaround untill we release version with fix is to add code below into Toad.exe.config in Program Files directory. It must be placed at the beginning of file, right after configuration tag (line 3).
<configSections> <sectionGroup name="system.data.dataset.serialization" type="System.Data.SerializationSettingsSectionGroup, System.Data, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b77a5c561934e089"> <section name="allowedTypes" type="System.Data.AllowedTypesSectionHandler, System.Data, Version=220.127.116.11, Culture=neutral, PublicKeyToken=b77a5c561934e089"/> </sectionGroup> </configSections> <system.data.dataset.serialization> <allowedTypes> <add type="Quest.Toad.QueryBuilder.WhereClauseClass, ToadCore" /> </allowedTypes> </system.data.dataset.serialization>
If issue persists, please let me know.
@StanislavLobodzinski We had many users encountering this issue after a company wide Windows update (which I'm assuming contained the previously mentioned KB articles). Your workaround seems to have done the trick with regards to the DB issue!
Also, a few users have noticed that some of their TDP settings were reset to default following the Windows update, such as: the Local Storage and Toad Export paths, unchecked multiple TDP instances box, and TDP customized skins. Any idea if these are related?
This is causing a launch issue with version 18.104.22.1688
System.IO.FileNotFoundException Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified. Stack Trace: at Quest.Toad.Map.MapValidation.HasLocalCommunityEditionTIC() at Quest.Toad.Map.MapValidation.SetCurrentToadOption() at Quest.Toad.Map.MapValidation.SetOptionsAndCheckIdentity() at Quest.Toad.Map.MapValidation.Initialize() at Quest.Toad.Map.MapValidation.get_InstalledPlatforms() at Quest.Toad.Map.MapValidation.get_InstalledPlatformTypes() at Quest.Toad.Util.Global.get_MutexAppCode() at Quest.Toad.StartupForm.MainAppicationEntryPoint(String args) at Quest.Toad.ToadProcessEntryPoint.Main(String args) System.ComponentModel.Win32Exception Invalid window handle Stack Trace: at MS.Win32.UnsafeNativeMethods.CreateWindowEx(Int32 dwExStyle, String lpszClassName, String lpszWindowName, Int32 style, Int32 x, Int32 y, Int32 width, Int32 height, HandleRef hWndParent, HandleRef hMenu, HandleRef hInst, Object pvParam) at MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook hooks) at System.Windows.Interop.HwndSource.Initialize(HwndSourceParameters parameters) at System.Windows.Window.CreateSourceWindow(Boolean duringShow) at System.Windows.Window.CreateSourceWindowDuringShow() at System.Windows.Window.SafeCreateWindowDuringShow() at System.Windows.Window.ShowHelper(Object booleanBox) at System.Windows.Window.Show() at Quest.Toad.Exceptions.Unhandled.ForceApplicationShutdown.CreateWPFWindowDelegate(Object state) at Quest.Toad.Gui.WPFWindowThread.<>c__DisplayClass6.<DisplayWPFWindow>b__3() at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) at System.Windows.Threading.DispatcherOperation.InvokeImpl() at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state) at System.Windows.Threading.DispatcherOperation.Invoke() at System.Windows.Threading.Dispatcher.ProcessQueue() at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam) at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg) at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame) at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame) at Quest.Toad.Gui.WPFWindowThread.CreateDispatcherThread()
Not sure if settings reset could be related to this, but I will check that.
Looks like Toad.exe.config gets corrupted on edit. Could you please verify if copy-paste didn't add any unwanted characters to it? Also runtime section must remain untouched.
I've sent a copy of the logs and config file to Filip Cevela's email, I had removed control characters and line spacing from the file before applying it, but I'll double check.
I left out the first line configSections, my mistake, fixed and works.