Devart Forums

Problem solved. Through trial and error, determined it was the Unidirectional = True, and then reading the help file, it does say that setting Unidirectional = True makes the dataset read-only.

When I issue the statement IBCTable1.Append I get an exception "cannot modify a read-only dataset". Not seeing why the table is being treated as read-only

[code] IBCConnection1 := TIBCConnection.Create(nil);
IBCTransaction1 := TIBCTransaction.Create(nil);
IBCQuery1 := TIBCQuery.Create(nil);
IBCTable1 := TIBCTable.Create(nil);

IBCConnection1.Server := gIBServer;
IBCConnection1.DefaultTransaction := IBCTransaction1;
IBCConnection1.Username := 'SYSDBA';
IBCConnection1.Password := 'masterkey';
IBCConnection1.Database := 'C:\IBDATA\MAILER.IB';
IBCConnection1.AutoCommit := True;

IBCTransaction1.DefaultConnection := IBCConnection1;
IBCTransaction1.IsolationLevel := iblCustom;
IBCTransaction1.Params.Add('read');
IBCTransaction1.Params.Add('write');
IBCTransaction1.Params.Add('wait');
IBCTransaction1.Params.Add('concurrency');

IBCQuery1.Connection := IBCConnection1;
IBCQuery1.AutoCommit := True;
IBCQuery1.UniDirectional := True;
IBCQuery1.Transaction := IBCTransaction1;

IBCTable1.Connection := IBCConnection1;
IBCTable1.KeyGenerator := 'IDXGEN';
IBCTable1.ReadOnly := False;
IBCTable1.Transaction := IBCTransaction1;
IBCTable1.UniDirectional := True;
IBCTable1.TableName := 'MAIL';
IBCTable1.UpdateTransaction := IBCTransaction1;
IBCTable1.AutoCommit := True;

IBCConnection1.Connected := True;
IBCTable1.Active := True;
[/code]

I'm afraid that's impossible, I can't send you my Interbase installation. If you guys lack the skill to read your own code in .Prepare to see why it's creating and then trying to modify an active transaction, then there really is no chance you'll be able to fix it.

Thanks anyway.

As a workaround to AutoCommit being broken, I changed the Execut above to :

zdbu.IBCTransaction1.StartTransaction;
zdbu.IBCQuery1.Execute;
zdbu.IBCTransaction1.Commit;

and this works. However, I ran into yet another bug with IBDAC:

zdbu.IBCTransaction1.StartTransaction;
zdbu.IBCQuery1.Execute;
zdbu.IBCTransaction1.Commit;

zdbu.IBCQuery1.Close;
zdbu.IBCQuery1.SQL.Clear;
zdbu.IBCQuery1.SQL.Add('INSERT INTO DEVAPP(IDXNO,DEVID,UPDSTATUS,UPDPKGID,VERSION,FILEVERSION,FILEDATE,ISBANNED,ISACTIVE,APPDATE,APPID) ');
zdbu.IBCQuery1.SQL.Add('VALUES(GEN_ID(IDXGEN,1),:DEVID,:UPDSTATUS,:UPDPKGID,:VERSION,:FILEVERSION,:FILEDATE,:ISBANNED,:ISACTIVE,:APPDATE,:APPID);');

zdbu.IBCQuery1.Prepare;

>> Exception: "can not perform operation on an active transaction"

What gives ? The previous transaction was committed, the query was closed. Why is Prepare starting a transaction ?

So I have the following in a multithreaded application. Each thread has it's own connection, query and transaction:

zuser.IBCTransaction1.DefaultConnection := zuser.IBCConnection1;
zuser.IBCTransaction1.IsolationLevel := iblCustom;
zuser.IBCTransaction1.Params.Add('read');
zuser.IBCTransaction1.Params.Add('write');
zuser.IBCTransaction1.Params.Add('wait');
zuser.IBCTransaction1.Params.Add('concurrency');

and then I try to perform:

zdbu.IBCQuery1.Close;
zdbu.IBCQuery1.SQL.Clear;
zdbu.IBCQuery1.SQL.Add('UPDATE DEVICE SET LCALLDATE = :LCALLDATE ');
zdbu.IBCQuery1.SQL.Add('WHERE DEVID = :DEVID;');

zdbu.IBCQuery1.ParamByName('LCALLDATE').AsDateTime := Now;
zdbu.IBCQuery1.ParamByName('DEVID').AsString := string(zdev.deviceid);

zdbu.IBCQuery1.Execute;
zdbu.IBCQuery1.Close;


There are three threads. Each thread executes the update about two seconds after the last thread, so there is ample time for the commit to occur. Threads 1 and 2 execute fine. Thread 3 gets an exception "deadlock update conflicts with concurrent update'.

Why is this ? Why is IBDAC not committing the transaction when I close the TIBCQuery ? If I add a line after the update saying "COMMIT;" then I get an error saying COMMIT not a valid keyword. There would be no conflict if IBDAC was actually doing a commit, so I have to think IBDAC is broken.

That isn't true though. Setting iblSnapshot sets the NOWAIT option. I want to use WAIT so I must use iblCustom, which is fine. The interbase Language Reference specifies that SNAPSHOT is the valid IsolationLevel parameter to use. IBDAC dos not allow that keyword. That API guide is for use with C++, but I am using Delphi. I would expect IBDAC to use what the Language Reference says are the valid keywords.

New versions of UniDAC and ODAC are out, but I can't install them until IBDAC 7.25 is released. Any idea when that will be ?

IBCTransaction in the parameter strings does not accept snapshot. In fact it doesn't accept hardly any pf the Interbase options, read, write and wait are all it takes. Devart has used custom names like concurrency or read_comitted. Why don't you guys use the real names ? What do concurrency or consistency even mean, it's not documented anywhere what parms are valid in the Params stringlist.

I'm using Delphi 10.3.2 with IBDAC 7.2 on Win 7. I execute the following to create some Interbase tables:

procedure TForm5.Button4Click(Sender: TObject);
begin
try
CodeSite.Send('Deleting All Gymlete Tables');
DropTables.Execute;
except
on E: Exception do
begin
CodeSite.Send('eXCEPTION DETECTED');
CodeSite.SendException(E);
CodeSite.SendError(Format('Drop Tables failed: %s',[E.Message]));
ExceptionManager.StandardEurekaNotify(ExceptObject, ExceptAddr);
end;
end;

The first Codesite message gets sent. The IBScript component throws an exception for "metadata error - table not found" when some of the tables don't exist, which is fine. The problem is that my on E: Exception is not getting control. None of the Codesite error messages in the except block are issued.

So then I tried disabling Eurekalog altogether, and now I get a MS-style dialog box about the metadata error. So I'm guessing that the IBScript component is itself trapping the exception. Is that correct ? If that is true, how do I get it to stop doing that because I want to handle any exceptions myself.

I must be doing something wrong, getting SQL error:


cncMail := TIBCConnection.Create(nil);

cncMail.Server := gIBServer;
--- server stuff here ---

trnMail := TIBCTransaction.Create(nil);
trnMail.DefaultConnection := cncMail;
trnMail.Params.Clear;
trnMail.Params.Add('WRITE');
trnMail.Params.Add('WAIT');
trnMail.Params.Add('READ_COMMITTED');

qryMail := TIBCQuery.Create(nil);
qryMail.Connection := cncMail;
qryMail.LockMode := lmLockImmediate;
qryMail.Transaction := trnMail;

cncMail.Connect;

then later when I have 3 threads running and they are all trying to do like this:

Executing query <UPDATE EMAIL SET LOCKID = '00000003' WHERE LOCKID = '00000000' AND SENT = FALSE ROWS 1>
MailTask: SQL Error: lock conflict on no wait transaction

why is it saying nowait ? I said WAIT in the params. What am I doing wrong ? Also, "READ COMMITTED" is flagged as error, but that is what Interbase API says, you're using different terms.

When you add SQL statements to the SQLINSERT, SQLUPDATE etc. properties, if you used parameters, then how do you access them to set the values, as in how do you specify a ParamByName for those options and not the .SQL property ? Or prepare them, because the Prepare method works against the .SQL stringlist, not the others.

Actively refused points to a port error. Either firewall is blocking or port 3050 is not actually the listener port.

I see. Thanks for the explanation.

Your answer of "You cannot work with InterBase 6 on the iOS platform because InterBase supports iOS starting from InterBase XE3 ToGo." makes no sense. He didn't ask you if he could use Interbase on a mobile device.

The question was "Would it be possible to connect to a remote Interbase 6 server with an iOS using IBDac?". Is it possible to use IBDAC to connect to a remote IB 6 server. I don't see why the answer would not be yes, but who knows. Unless IBDAC itself does not work on either iOS or Android, but the product page says it does.

Does TUniTable work with the underlying table directly or does it just convert each operation into SQL statements such that I would be better off just using TUniQuery directly ?

I ask because often the examples given here show an SQL statement for the SELECT and then instead of using an Update will be shown a .Edit, fieldbyname = someval, .post operation. It makes me wonder if the table methods are a little faster than using SQL statements. But if TUniTable just calls TUniQuery under the covers then no reason to use it for that.