Search found 8 matches

by carlmon
Wed 06 May 2020 14:02
Forum: SQL Server Data Access Components
Topic: SDAC installer reading lsass.exe process memory
Replies: 1
Views: 3305

SDAC installer reading lsass.exe process memory

Hi,

Our AV (Carbon Black) was triggered by the SDAC installer. It seems to be reading the lsass.exe process' memory where Windows credentials are kept. Is this intended and why is it needed?

Some screenshots for further detail:
Image
Image
by carlmon
Thu 02 May 2019 09:38
Forum: SQL Server Data Access Components
Topic: TrustServerCertificate not working with MSOLEDB provider
Replies: 2
Views: 5402

Re: TrustServerCertificate not working with MSOLEDB provider

I added the following code to OLEDBAccess.pas' SetConnectionProperties proc and it seems to work.

Code: Select all

if (GUIDToString(FProviderId) = GUIDToString(CLSID_MSOLEDBSQL)) and GetConnection.Options.TrustServerCertificate then
    AddPropBool(SSPROP_INIT_TRUST_SERVER_CERTIFICATE, GetConnection.Options.TrustServerCertificate);
It looks like SDAC also excludes MARS and ro/rw intents for the new msoledbsql provider. Will this be addressed?
by carlmon
Mon 29 Apr 2019 11:03
Forum: SQL Server Data Access Components
Topic: TrustServerCertificate not working with MSOLEDB provider
Replies: 2
Views: 5402

TrustServerCertificate not working with MSOLEDB provider

Hi,

When I enable encryption and explicitly trust the server's TLS certificate with the MSOLEDB.1 provider, I get the the following error:
SSL Provider: The certificate chain was issued by an authority that is not trusted.
This used to only happen when TrustServerCertificate is FALSE on previous providers. With MSOLEDB.1, the TrustServerCertificate setting does not seem to make a difference.

How can I make encryption work on the new provider without trusted certificates? We will typically use trusted certs in production, but not in other environments.

Thanks,
Carl
by carlmon
Wed 25 Aug 2010 11:47
Forum: SQL Server Data Access Components
Topic: TMSLoader "Unspecified Error" exception in new versions...
Replies: 1
Views: 1683

TMSLoader "Unspecified Error" exception in new versions...

Greetings,

We use TMSLoader to batch insert data into a few tables without doing PutColumnData() on NOT NULL identity columns. This used to work before we upgraded, but now it raises "Unspecified Error" exceptions.

Is this change intentional?

I attach TSQL and Delphi 5 code to reproduce.

Thanks,
Carl

Code: Select all

CREATE DATABASE TestDB
GO

USE TestDB
GO

CREATE TABLE Temp_Table
(
	a INTEGER IDENTITY NOT NULL,
	b INTEGER NOT NULL,
	c INTEGER
)

Code: Select all

program SDACTest;
{$APPTYPE CONSOLE}

uses
  SysUtils, MSAccess, MSLoader, ActiveX;

type
  TTestDataGenerator = class
  public
    procedure LoadTestData(Sender: TMSLoader);
  end;

procedure TTestDataGenerator.LoadTestData(Sender: TMSLoader);
var
  iRow: Integer;
begin
  for iRow := 1 to 3 do
  begin
//Uncomment this to fix the error:
//    Sender.PutColumnData('a', iRow, 1);

    Sender.PutColumnData('b', iRow, 2);
    Sender.PutColumnData('c', iRow, NULL);
  end;
end;

var
  Connection: TMSConnection;
  Loader: TMSLoader;
  TestDataGenerator: TTestDataGenerator;
begin
  try
    CoInitialize(nil);
    Connection := TMSConnection.Create(nil);
    TestDataGenerator := TTestDataGenerator.Create;
    Loader := TMSLoader.Create(nil);
    try
      Connection.ConnectString := 'Data Source=.;Initial Catalog=TestDB;User Id=sa;Password=;';
      Connection.Connect;

      Loader.Connection := Connection;
      Loader.TableName := 'Temp_Table';
      Loader.CreateColumns; //Load the table structure
      Loader.OnPutData := TestDataGenerator.LoadTestData;
      Loader.Load;
    finally
      Loader.Free;
      TestDataGenerator.Free;
      Connection.Free;
      CoUninitialize;
    end;

  except
    on Exc: Exception do
      WriteLn(Format('%s: %s', [Exc.ClassName, Exc.Message]));
  end;

  Writeln('Done.');
  Readln;
end.
by carlmon
Tue 28 Oct 2008 14:24
Forum: SQL Server Data Access Components
Topic: Problem with derived sort order
Replies: 6
Views: 3853

Thanks Dimon,

I sent you an example application if you still need to replicate this.

Could you confirm that it is safe to modify TCustomDADataSet.PSGetDefaultOrder to always return nil?

Regards,
Carl
by carlmon
Mon 20 Oct 2008 13:47
Forum: SQL Server Data Access Components
Topic: Problem with derived sort order
Replies: 6
Views: 3853

I just did some further investigation. It looks like TCustomDADataSet.PSGetDefaultOrder orders by whichever ORDER BY fields exist in the SELECT list. Any missing ORDER BY fields are simply ignored.

Please advise on a fix/workaround.

Regards,
Carl
by carlmon
Mon 20 Oct 2008 13:05
Forum: SQL Server Data Access Components
Topic: Problem with derived sort order
Replies: 6
Views: 3853

Hi Challenger,

Thanks for the reply, but poRetainServerOrder is not one of the options in Delphi 5... Here is the complete option set:

TProviderOption = (poFetchBlobsOnDemand, poFetchDetailsOnDemand,
poIncFieldProps, poCascadeDeletes, poCascadeUpdates, poReadOnly,
poAllowMultiRecordUpdates, poDisableInserts, poDisableEdits,
poDisableDeletes, poNoReset, poAutoRefresh, poPropogateChanges,
poAllowCommandText);

Regards,
Carl
by carlmon
Thu 16 Oct 2008 10:12
Forum: SQL Server Data Access Components
Topic: Problem with derived sort order
Replies: 6
Views: 3853

Problem with derived sort order

Greetings,

We recently upgraded from 3.80 to 4.50(.0.36) and are experiencing issues with the order of returned queries.

I have traced the problem to the following example scenario:

A clean, newly created TClientDataset is populated from:
" SELECT LastName
FROM Customer
ORDER BY CustomerID, FirstName, LastName "

The DataSet comes back ordered by LastName (not CustomerID and FirstName first). On inspecting the DataSet, I see LastName was somehow added to the DataSet's .IndexFields, but .IndexFieldNames is blank. The dataset should have no explicit sorting - just retain SQL Server's query result record order.

Adding FirstName and CustomerID to the SELECT list 'resolves' the sorting issue. Unfortunately this is not a solution as we have many reports on many implementations.

Is there any way to turn off this behaviour? It worked fine on 3.80.

Please advise.

Thanks,
Carl