We use VBA to retrieve data from an Oracle database using the Microsoft.ACE.OLEDB.12.0 provider.
We have used this method without issue for a long time, but we have encountered a problem with a specific query of data from a specific table.
When running it under VBA, we get "Run-Time error '1004': Application-defined or object-defined error. However investigating further, we find the following:
The queries we run are dynamically generated, and how we handle them is to read the results into a variant array, then output that array into Excel. When we step-through our particular query, we find that one specific database field is "blank": The locals window shows the value to be completely blank: it is not an empty string, it is not a null, it is not zero. VarType() shows it to be a decimal data type, and yet it is empty.
I can't seem to prevent this error from locking-out:
On Error Resume Next
...still breaks.
if (isEmpty(theValue)) then
...doesn't catch it, because it is not empty
if (theValue is nothing) then
...doesn't catch it because it is not an object
etc.
We used the SQL in the a .NET application, and got a more informative error:
Decimal's scale value must be between 0 and 28, inclusive. Parameter name: Scale
So: I see this as two issues:
1.) In VBA, how do I trap the variant datatype value-that-is-not-empty-or-null, and;
2.) How do I resolve the Oracle Decimal problem?
For #2, I see from the Oracle decimal data type, it can support precision of up to 31 places, and I assume that the provider I am using can only support 28. I guess I need to Cast it to a smaller type in the query.
Any other thoughts?
Related
I build a dynamic Dictionary in ClickHouse DB. It will create the dictionary before the SQL commands execute. Also, the dictionary name was created at the same time.
The dictionary name was a combined string by date and table name. Because I don't want to keep so much data in the long-term dictionary, the short-term Dictionary could be a great help to release the memory after maybe an hour when no one is using it.
And the error happened.
When I use the dictionary in my SQL commands it is okay with solid commands.
e.g.
dictGet(CONCAT('2022-04-06', 'MyTableName'), 'GetBackColumnName',myKeyColumn) AS col_name
But when I change to using the column from Table, it was broken.
e.g.
dictGet(CONCAT(DATE_COL, 'MyTableName'), 'GetBackColumnName',myKeyColumn) AS col_name
And the error message shows up.
Illegal type String of the first argument of function dictGet,
expected a const string.
Does anyone know how to fix the issue?
My CH version is: 20.8.7.15
I try to find the resolution from the ClickHouse office report but nothing can fix this issue. And I tried lots of functions of String to figure out what happened.
Hello everyone and happy new year,
I'm converting my project to use SQL Server instead of MySQL and I'm struggling with the problem of managing timestamps.
In the project, I have this code:
Customers::whereBetween('created_at', [Carbon::now()->subDays('7'), Carbon::now()])->count();
which gives me back the number of new customers registered in the last 7 days.
Using MySQL no problem whatsoever while with SQL Server I get this error:
Converting an nvarchar data type to datetime resulted in a value
outside of the allowable range.
despite in my model, I have set
public function getDateFormat()
{
return 'Y-m-d H: i: s.v';
}
to get the values in milliseconds.
What did I forget to set up?
The error tells you that a conversion failed. Possible reasons:
The date does not exist
If you get February 30th as the input, it will fail.
Input not complying to the format in use
To detect whether this is the problem, you will need to find out what the generated SQL is and find out which value caused this problem. After carefully studying the conversion you should be able to determine what the problem and solution is.
Using Delphi 2007.
We do not use the designer to configure our DataSet. It is built automatically from the SQL query. So we need a solution where the fields are built at runtime.
I need to SELECT a large number (e.g. 2305843009213693951) from a NUMBER(19,0) column in Oracle using ADO. Our query works in SQLServer where the column is defined as BIGINT and is mapped automatically to a TLargeintField but for Oracle it is mapped to TBCDField. This behaviour is documented in a couple of places for instance here - TADOQuery.EnableBCD.
The problem (as mentioned in the same page) is that our number is in some instances too large and an overflow exception is thrown (it uses decimal under the hood). As expected / documented - if I use TADOQuery.EnableBCD(false) then the column is mapped to a TLargeintField which is what I want. However this option is set for all columns and seems a bit heavy handed.
An alternative is described:
Note: For fields with very large numbers of more than 19 significant digits, you can use TVariantField type persistent field objects. The TFloatField and TBCDField classes lack sufficient capacity for fields of this size. TVariantField allows the getting and setting of the field data as strings, preventing without loss of data due to insufficient capacity. However, arithmetic operations cannot be performed on numbers accessed through a TVariantField object.
So I tried configuring the fields to columns manually as described in this article - Creating a ClientDataSet's Structure at Runtime using TFields. But this doesn't appear to work as I get the exception: "Type mismatch for field 'total_rec' expecting: LargeInt actual: BCD'.
So is there a way to force ADO to return the dataset with a field of type TLargeintField for a NUMBER(19,0) without using the designer?
Interestingly ODAC maps the column to TLargeintField, but we are supposed to support ODAC and ADO.
I don't believe there is a way to manually control column data types returned by the ADOQuery. I tested overriding the procedure mentioned by kobik which determines the data type and this worked well. However we are not going to use this solution because I looked at the same code in XE4 and it appears it has been modified for use with large BCD numbers. We can wait until we upgrade from 2007 (hopefully next year).
The code I added to my overridden version of InternalInitFieldDefs was:
After
if (F.Type_ = adNumeric) and (F.NumericScale = 0) and (F.Precision < 10) then
begin
FieldType := TFieldType(ftInteger);
end
I added
else if (F.Type_ = adNumeric) and (F.NumericScale = 0) and (F.Precision >= 19) then
begin
FieldType := ftLargeint;
end;
While executing a DB2 (V8) Stored Procedure, I get the following error :
SQL0304N A value cannot be assigned to a host variable because the value is
not within the range of the host variable's data type. SQLSTATE=22003
I did not set any kind of tracing or specific error handling and as the error only occurs in our client's validation environment that I'm not allowed to play with, I do not have many options but analyze my code again.
Here is the result of my current analysis. Google is not much of a help...
My "10 pages" procedure creates a CURSOR over a set of data, goes though it and computes values for each element to be inserted it in a table.
I have checked (hopefully) all my variables types versus data types used to fill them and versus the data types of the target table and I do not see any conflict there.
Since there are a lot of decimal numbers, multiplications and additions, my only hypothesis is that a computed value becomes too large for a defined variable. Could anyone confirm that would be the "correct error" ? And would it also apply if the number of digits after the decimal point generated by computing is greater than allowed by the targeted variable type (eg. 100000.123 in decimal(6,2)) ?
I also tried to find a way to debug db2 pl sql through a client but I did not find any solution. If you have any suggestion...
Many thanks in advance for any clue :)
I answer myself...
First, my last question => I did not find any way to debug db2 pl sql through a client (with DB2 V8 at least).
After I was authorized to work on our integration client's environment, I could confirm my hypothesis was right. The variable format receiving the multiplication was sometimes too small (decimal(10,2)) for the computed result.
The solution adopted was to change the variable format to decimal(15,2) and since the final value to insert still had to be decimal(10,2) upon client's requirements, we validated the following with our client :
1-Check the variable value :
if (myval > 9999999,99)
then
set myval = 9999999,99;
end if;
=> "back to decimal(10,2) requirement"
2-Get back to decimal(10,2) at insert :
This last bit of code also solves the issue when there are too many digits after the decimal point. That was causing an error as well at insert time
insert into mytable values (
... ,
CAST(myval AS DECIMAL( 12 , 2 )),
...
)
This is my first attempt to create a Visual Studio 2008 report using parameters. I have created the dataset and the report. If I run it with a hard-coded filter on a column the report runs fine. When I change the filter to '?' I keep getting this error:
No overload for method 'Fill' takes '1' argument
Obviously I am missing some way to connect the parameter on the dataset to a report parameter. I have defined a report parameter using the Report/Report Parameter screen. But how does that report parameter get tied to the dataset table parameter? Is there a special naming convention for the parameter?
I have Googled this a half dozen times and read the msdn documentation but the examples all seem to use a different approach (like creating a SQL query rather then a table based dataset) or entering the parameter name as "=Parameters!name.value" but I can't figure out where to do that. One msdn example suggestted I needed to create some C# code using a SetParameters() method to make the connection. Is that how it is done?
If anyone can recommend a good walk-through I'd appreciate it.
Edit:
After more reading it appears I don't need report parameters at all. I am simply trying to add a parameter to the database query. So I would create a text box on the form, get the user's input, then apply that parameter programmatically to the fill() argument list. The report parameter on the other hand is an ad-hoc value generally entered by a user that you want to appear on the report. But there is no relationship between report parameters and query/dataset parameters. Is that correct?
My last assumption appears to be correct. After 30 years in the industry my bias is to assume a report parameter actually filters the SQL data using the given parameter. This is not the case with .rdlc files used by Report Viewer. These report parameters have nothing to do with fetching data. Sounds like this was a design decision on Microsoft's part to completely separate the display of data from the fetching of data, hence, Report Viewer has no knowledge of how data may be fetched. Best way for me to conceptualize this dichotomy is to think of Report Parameters more as Report Labels, quite distinct from the dataset query parameters.