Devart Forums

Posted: **Thu 10 Dec 2009 10:28**

We're investigating your product as part of a fairly complicated migration procedure. We have an existing suite of delphi applications talk to an Oracle backend via DOA.

We're looking at talking to a MSSQL db and an Oracle db backend from the same code, which is where the UniDAC components come in. For the main part I have very quickly managed to get UniDAC talking to both MSSQL and Oracle without issue, however I'm having issues with floats / integers.

In our current oracle database all our ID fields are declared as number(9), these have been migrated into our MSSQL database as numeric(9,0). We need this type due to the precision (length of numbers). In our current delphi implmentation these are represented as TFloatfield which seems to work for MSSQL however when talking to Oracle I get the following error message;

'Expecting Float actual integer'

Within the help that came with trial under the page 'Using UniDAC with Oracle' there is a section on TUniConnection;

Code: Select all

EnableIntegers : When set to True, the provider maps Oracle numbers with precision less than 10 to TIntegerField. If EnableIntegers is set to False, numbers are mapped to TFloatField or XXX.

This would imply to do exactly what we need .. however it is not a property on the Connection component and when I try do something like;

Code: Select all

fDBSession.SpecificOptions.Values['EnableIntegers'] := 'False';

It doesn't work either. Am I missing something or is there another way to go about this?

Posted: **Fri 11 Dec 2009 08:48**

There is a mistake in the help.

You should set the PrecisionInteger specific option to 0 to disable TIntegerField.

Posted: **Fri 11 Dec 2009 09:04**

Thankyou for the reply .. I had solved it by doing the following;

Code: Select all

      for j := self.fieldList.count-1 downto 0 do
      begin
        if TField(self.fieldList[j]).dataType = ftFloat then
        begin
          myOldField := TField(self.fieldList[j]);

          self.owner.removeComponent(myOldField);

          myNewField := TIntegerField.create(self.owner);

          myNewField.FieldName := myOldField.FieldName;
          myNewField.FieldKind := fkData;
          myNewField.Name := myOldField.Name;
          myOldDataset := myOldField.Dataset;
          myOldField.free;
          myNewField.DataSet := myOldDataset;
        end;
      end;

but hopefully the solution you have given is slightly more elegant as this is a pretty horrible hack.

I do have a second question and I appreciate this may be better splitting off onto a second topic.

Is there a way to tell the number of records inside the clientdataset. So for example you have a million records in your table, you pull back the first 50. Is there a way to tell that there is 50 records in your dataset currently ?

Posted: **Mon 14 Dec 2009 08:39**

You can limit the number of record only by modifying the SQL statement.

Posted: **Wed 16 Dec 2009 08:21**

Plash wrote:You can limit the number of record only by modifying the SQL statement.

So does fetchRows on TUniQuery only limit the size of the packet across the network not the size of the dataset?

This is quite a serious issue if we need to do it through SQL as different databases do 'pagination' in different ways, it would also mean a migration of 10's of thousands of pieces of SQL and correspondingly splitting them into a piece of SQL for each database technology.

Posted: **Fri 18 Dec 2009 10:44**

FetchRows sets the number of records in a block but does not limit total number of records.

You can try to use the BeforeFetch event. In this event you can set the Cancel parameter to True and interrupt fetching if there are enough records in dataset.

Posted: **Mon 04 Jan 2010 10:36**

Plash wrote:FetchRows sets the number of records in a block but does not limit total number of records.

I think you've misunderstood what I meant. I don't want to limit the total number of records I want to find out the number of records currently in the ClientDataset, and yes control the flow of records in blocks (ie packets). This is cursor functionality, only fetching the records on demand.