Devart Forums

Thank you! Yes, NonBlocking := False works well.

Hi!

To reproduce it place on form
MSConnection
MSQuery

Set MSQuery1.Options.NonBocking := True
Set MSQuery1.SQL.Text any SELECT query

Add code below in button on click and execute the code

TThread.CreateAnonymousThread(
procedure
begin
CoInitialize(nil);
try
MSQuery1.Close;
MSQuery1.Open;
finally
CoUninitialize;
end;
end).Start;

set debug point on MSQuery1.Close and run (F9) in debug mode, on first executing (click button) this code it's ok but on second executing (click button) you will see error 'Not enough timers available' on line 'MSQuery1.Close'.

This problem happened in CRTimer unit in code

procedure TCRTimer.UpdateTimer;
begin
KillTimer(FWindowHandle, 1);
if (FInterval <> 0) and FEnabled and Assigned(FOnTimer) then
if SetTimer(FWindowHandle, 1, FInterval, nil) = 0 then
raise EOutOfResources.Create(SNoTimers);
end;

What was changed in SDAC that components brings this error and how to fix it? Also, as I understand that NonBocking options is used especially for threads but now looks like NonBocking := false works good.

Thank you.

Hi,

Thank you so much.

Hi,

Yes, you're right. But both {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} and XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX are correct too, so what's problem to check ingoing value on existing of brackets? When I got this strange error i spent lot of time to figure out, what's problem. For MS SQL Server both values are correct. I can receive GUID value from different sources, and I can get GUID without brackets in this case i will receive this strange error. This mean that I need to check every GUID on existing of brackets. I cannot believe that you think this that it good solution.

For my opinion it's bug or bad architecture.

Hi,

I use last version of SDAC (8.2.8) for RAD Studio 10.2 + MS SQL Server 2012.

Tested with TMSQuery. I found bug on adding GUID data. For example you have table with uniqueidentifier column and trying to add data from client application that use TMSQuery.

If you pass such value {00000000-0000-0000-0000-000000000001} - everything fine.
But if you pass value without brackets 00000000-0000-0000-0000-000000000001 application shows exception: Invalid class string.

Thanks,
Alexey

Two months later, this problem still persists in 7.0.1. Could you please fix this problem.

Thank you very much, it's very good news.

Thank you for your update.

And could you please detect AM/PM format in time (when it mapped from TWideString to TTime) and convert to the 'hh:mm:ss' format on posting to database? I spent a lot of time to find a place to fix the problem. I think it have to be fixed because in American format of time it always raises error.

Unfortunately, on 6.11.22 the problem still occurs.

I did a project on which you can observe this problem:

www.createmark.com/exchange/test.zip

Just to show the problem www.createmark.com/exchange/time_problem.png

Also, for the latest version of the component, I found bug.
If MSQuery ParamCheck is false such SQL:

{CALL System.uspExecuteXSQL (:AXSQL)}

occurs to error message “List index out of bounds (0).” on open/close SQL dialog or open form.

Just to show the problem www.createmark.com/exchange/bug.png

Thank you for your answer.

But I need to use exactly prSQL cause SQL Native Client (MS SQL Server 2012) can be installed only on Vista or above. So to support WinXP I use prSQL.

As I indicated in my first message the problem is in components that does not check for AM/PM format and it brings to this error.

Hi!

We've encountered such problem, we have a field with 'time' type on our server (MS SQL Server 2012). PrSQL provider is set in the options of TMSConnection component on the client. Thus, in the dataset server type 'time' is recognized as TWideString. We have manually changed the type to TTime and created mapping rule for this exact field (DataSet.DataTypeMap.AddFieldNameRule('SomeFieldName', ftTime), its type is recognized as TTime.

In case time format in MS Windows is set to 24 hours and not AM/PM, everything is fine. But when we use American settings (i.e. AM/PM time format), then during the data update we get this error: Value is too long: 22:00:00.

I digged in the code a bit and found that TCRRecordSet.PutFieldData procedure invokes the data accuracy check function that compares the length of '10:00:00 PM' to 8 (a TTime type size). Thus the data is considered inaccurate because 10:00:00 PM is longer and therefore update isn't completed. An interesting thing is that an incorrect value is got before the error message shows (GetDataAsVariant function), this value retrieves time in 24 hours format, i.e. 22:00:00.

Please advise how to correct this so that we can use AM/PM time format. Maybe you could provide a fix for this error?

Thank you.