Re: NexusDb

> At no time did I query your evaluation of the SQL statements.
> In fact, I said that you showed that the SQL tests were badly
> designed, or words to that effect.

Thank you.

> That really only leaves the question of Transactions IMO.
....
> The only reason that I did not concede the point on transactions is
> because what has been posted seems to be very vague about
> the question of transactions.

IMO, it may appear to be vague because the author's initial statement is
vague and IMO the conclusions you want to reach are not taking into account
what transactions are and how they are used.

I'm going to try to be as clear and direct as I can.

The author says: > > Transactions cannot be accomplished through SQL,

"through SQL" is ambigious. ISTM, that you have interpreted this as
specific SQL commands that support starting, commiting and rolling back
transactions. If this is the interpretation, then no, Nexus V1 does not
support this.

If OTOH, it is absolutely false if one interprets this as: 1) SQL commands
do not execute within the context of a transaction or 2) there is no ability
to execute SQL commands within a transaction controlled in code.

Does this clear things up?

.....
> To me, it implies that Start Transaction and Rollback are not
> supported, and that to achieve transactions, it is necessary
> to concetenate SQL statements.

No, that's not what those responses imply. Transactions are implemented in
the core DB engine, whether or not SQL exposes total control within SQL
itself does not mean that SQL queries don't execute within the context of a
transaction. To summarize:

1) Transactions are not dependent on SQL.
2) SQL statements always run within the context of a transaction.

The concatenation of SQL statements is a way to execute multiple SQL
statements through pure SQL within a transaction. It was mentioned to show
there is indeed transactional logic in every query NexusDB V1 executes.

> You also state the Interbase
> 6.5 also doesn't support Start Transaction. This is why it does not
> sound like a categoric statement that Nexus V1 supports
> Transactions. " (FWIW, Interbase 6.5 also doesn't support "START
> TRANSACTION")"
>
> Don't you agree?

I'm not sure what you mean by "This is why it does not sound like a
categoric statement that Nexus V1 supports Transactions".

What I intended to convey by mentioning Interbase is to provide an example
of a DB that supports transactions completely without the "START
TRANSACTION" statement. My assumption was that most Delphi developers are
familiar with Interbase and know beyond a shadow of a doubt that Interbase
supports transactions, therefore by extension, could recognize that NexusDB
V1 also supports transactions.

> If this is not the case, and Transactions are fully supported
> in V1, then I will concede that the author was totally wrong
> on that point.

The problem here is that your definition of "fully supported" seems to
include the support for SQL statements that control start/commit/rollback of
transactions. The fact is that transactions are "fully supported" in
NexusDB V1, but full control is not exposed through SQL commands.

Most developers that actually use NexusDB V1 don't have a problem with this
at all because in order to execute a SQL query in Delphi code you need to
have a TnxDatabase component anyway so you can control the transaction logic
there. And this is /really/ the most important point. When using NexusDB
V1 in your Delphi code, you don't miss or need start/commit/rollback SQL
commands.

> So, please clarify that Transactions are supported no, ifs,
> buts, maybe's, no need to concatenate SQL statements.

Is the above clear enough? If not, I'm not sure how to explain it to your
satisfaction. Without explicitly defining terms and completely
understanding the relationship between SQL and transactions I imagine any
accurate and thorough explanation will seem vague or wishy washy. Life is
complicated.

> No third party components, just straight out supports
> transactions as one would expect in the same way as
> other major products support SQL or at least as one
> would expect.

I'm not sure what you mean by "third party components". No where has anyone
mentioned any third party support adding transactional capability that I
recall. But this is an irrelevant point.

Everyone's expectations are different; NexusDB V1 meets my expectations of
transactional support using SQL or otherwise.

> If that is the case, then I concede that
> the author was wrong on that point also regarding Nexus V1.

Yes, please concede; he's wrong.

> I am not trying to be pedantic about it, it is just that so
> many claims are made (generally) that don't survive close
> scrutiny, or do what is said but not in the way expected.

Yes, but IMO you are being pedantic. And again, it continues to baffle me
why you don't apply that same scrutiny to the content of the article rather
than the content of these posts.

--
Brian Moelk
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
http://www.brainendeavor.com


.

Relevant Pages

  • Re: NexusDb
    ... > The SQL standard is there partly to make application code portable ... if something is done outside of SQL ... having support for transactions outside of SQL does not ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: Why is this query slow?
    ... I would be inclined to re-write the SQL statement to look something ... Co-author of "Expert Oracle Practices: ... SQL> insert into transactions values,'AAA'); ... where tx_date between sysdate -1 and sysdate +1 ...
    (comp.databases.oracle.server)
  • Re: NexusDb
    ... >> That really only leaves the question of Transactions IMO. ... >> The only reason that I did not concede the point on transactions is ... >> buts, maybe's, no need to concatenate SQL statements. ... >transactional support using SQL or otherwise. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: NexusDb
    ... >> because we mostly use SQL queries in our projects, SQL support is ... As evidence review your ... Whether this means that the SQL transactions have to be ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: What are some ADO & ASP.NET best practices
    ... Maybe it's a common query in your database not using ... dedicated to ADO.NET and SQL Server performance tips: ... Improving .NET Application Performance and Scalability ... >My next question is will transactions help to improve performance? ...
    (microsoft.public.dotnet.framework.adonet)