Tim,

Do I understand it correctly, that transaction always spans all tables
in the database? I.e. you cannot have two transactions started at the same
time? The parameter Tables in StartTransaction seem to be ignored (looks
so in source code). Is this correct?

Also, I can't seem to figure out what TEDBStringsArray is and how to pass
it in there.

Regards,
Michael

Michael,

<< Do I understand it correctly, that transaction always spans all tables in
the database? I.e. you cannot have two transactions started at the same
time? The parameter Tables in StartTransaction seem to be ignored (looks so
in source code). Is this correct? >>

That's fixed.  It was just an oversight.

<< Also, I can't seem to figure out what TEDBStringsArray is and how to pass
it in there. >>

It's a dynamic array of TEDBStrings, which are AnsiString or WideString
depending upon whether the version of EDB is ANSI or Unicode.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> That's fixed.  It was just an oversight.
Cool. When is b6?

> It's a dynamic array of TEDBStrings, which are AnsiString or WideString
> depending upon whether the version of EDB is ANSI or Unicode.
Could you give an example of how to provide the list?
I though StartTransaction(['table', 'table2']), but it doesn't
seem to work and I didn't find any description of that dynamic array.
I understand that it won't work in beta 5, but just curious.

Also, '*' & aliases are not treaded correctly in select:
Try these and see the plan.
select * from t d1, t d2
select d1.*, d2.* from t d1, t d2

While I have your attention a few suggestions for EDBManager:
1. Shortcut for execute query (e.g. Ctrl+E)
2. Don't hide SQL tab even if a table is selected
3. SQL history would be mighty helpful
4. SQL scripts (most databases do this in console, why can't EDBmgr. Just
add SET TERM pragma and that's it).


Regards,
Michael

Michael

> Could you give an example of how to provide the list?
> I though StartTransaction(['table', 'table2']), but it doesn't
> seem to work and I didn't find any description of that dynamic array.
> I understand that it won't work in beta 5, but just curious.

If this works like DBISAM, then you need to create a TStringList

   S := TStringList.Create;
   try
       S.Add('Table1');
       S.Add('Table2');
       Database.StartTransaction(S);
   finally
       S.Free;
   end;

Eduardo

Michael,

<< Cool. When is b6? >>

Either tonight or tomorrow.  I'm finishing up our example application to
include with the next build - CD Collector !!!  I bet you can't guess what
the application does....


<<  Could you give an example of how to provide the list? >>

It's a dynamic array, so you must declare it and set the array elements
manually:

var
  MyTablesArray: TEDBStringsArray;
begin
  SetLength(MyTablesArray,2);
  MyTablesArray[0]:='Test';
  MyTablesArray[1]:='Test2';

<< I though StartTransaction(['table', 'table2']), but it doesn't seem to
work and I didn't find any description of that dynamic array. I understand
that it won't work in beta 5, but just curious. >>

The special EDB* type synonyms will be in the next build's docs.

<< Also, '*' & aliases are not treaded correctly in select:
Try these and see the plan.
select * from t d1, t d2
select d1.*, d2.* from t d1, t d2 >>

Got it.  It only occurs when using the same table with different aliases.

<< While I have your attention a few suggestions for EDBManager:
1. Shortcut for execute query (e.g. Ctrl+E) >>

Okay.

<< 2. Don't hide SQL tab even if a table is selected >>

I'll have to think about this one to make sure that it won't make things
more confusing.

<< 3. SQL history would be mighty helpful >>

Already on the list.

<< 4. SQL scripts (most databases do this in console, why can't EDBmgr. Just
add SET TERM pragma and that's it). >>

I wanted to do SQL scripts like procedures, which means that it's different
than just firing a set of SQL statements at the engine.  I may end up just
throwing the script stuff back in there just like DBISAM to appease everyone
because no one seems to be interested in variables, branching, etc. in
scripts.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> << 4. SQL scripts (most databases do this in console, why can't EDBmgr. Just
> add SET TERM pragma and that's it). >>
>
> I wanted to do SQL scripts like procedures, which means that it's different
> than just firing a set of SQL statements at the engine.  I may end up just
> throwing the script stuff back in there just like DBISAM to appease everyone
> because no one seems to be interested in variables, branching, etc. in
> scripts.
Yes, I think that would be the most sensible thing to do - DBISAM's design was
actually quite good - only you will still have to invent a pragma, cause now you
have procedures with delimiters inside them, so SET TERM will just
make parsing easier (for me too . Another thing, that would be great is
to have execution blocks, like they have in firebird 2, where you can
execute PSM without creating a procedure ('execute block' statement iirc).
Now, if you combine the two it would be great. The problem with procedures
is that you have to escape SQL, which isn't convenient at all.

Also, using DDL in procedures is considered a deadly sin. There are so many
ways to shot yourself in a foot by doing so, that I'd only allow creation
of session-level temporary tables within procedures. The idea is that procedures
are something frequently used, while DDL is something that should be avoided
by all means


Michael

Tim


>I wanted to do SQL scripts like procedures, which means that it's different
>than just firing a set of SQL statements at the engine. I may end up just
>throwing the script stuff back in there just like DBISAM to appease everyone
>because no one seems to be interested in variables, branching, etc. in
>scripts.


I think its more like we don't know what good they would be or how to use them yet. If I'm interpreting your comments correctly it is possible to run scripts its just that you have to create a stored procedure first. If I'm right maybe all that's needed is a simpler way of getting from the scrip to the SP, running it and getting the result.

I do love words like simpler don't you <vbg>

Roy Lambert

Hello Tim,

> Either tonight or tomorrow.  

Unicode build pleeeeaaaaaseeeeeee ?????

> I'm finishing up our example application to
> include with the next build - CD Collector !!!  I bet you can't guess what
> the application does....

CD/MP3/OGG/ACC/MP4 catalog system ?? <bg>

--
Charalabos Michael - [Creation Power] - http://www.creationpower.com -
http://www.creationpower.gr

> include with the next build - CD Collector !!!  I bet you can't guess what
> the application does....
Hm. I went to search on google. CD I guess is a Certificate of Deposit.
And the Collector is probably somebody who makes you wanna do the deposit.
But I wouldn't know much about that business


Michael

Michael,

<< Yes, I think that would be the most sensible thing to do - DBISAM's
design was actually quite good >>

It wasn't *that* great.  It basically did the parsing and that was it.  The
rest was the same as if you had just fed the SQL statements one by one to
the TDBISAMQuery component.  EDB's stored procedures are much more versatile
and powerful.

<< Another thing, that would be great is to have execution blocks, like they
have in firebird 2, where you can execute PSM without creating a procedure
('execute block' statement iirc). Now, if you combine the two it would be
great. The problem with procedures is that you have to escape SQL, which
isn't convenient at all. >>

Your mixing two different things.  EXECUTE BLOCK *is* dynamic SQL, but the
fact that EDB requires the escaping of DDL and DML statements simply has to
do with what I've already stated - the ability to implement stored
procedures that aren't bound to the schema in any way other than procedure
calls and to allow for all SQL statements in a stored procedure, including
DDL.  The way I did it is the only way to do it and allow for these things.
And if I didn't do it this way, then DBISAM server-side procedures would not
be portable to EDB at all.

<< Also, using DDL in procedures is considered a deadly sin. There are so
many ways to shot yourself in a foot by doing so, that I'd only allow
creation of session-level temporary tables within procedures. >>

There's no way to do any harm with DDL in a stored procedure in EDB.  You
can't delete any referenced procedures and any SQL statements that reference
dropped or altered objects will simply issue the appropriate error.

<< The idea is that procedures are something frequently used, while DDL is
something that should be avoided by all means >>

The frequency of use doesn't matter with the way it is implemented in EDB.
You can PREPARE statements once and execute them as many times as you want
within the context of the stored procedure.  IOW, the pre-compilation
"benefits" of traditional stored procedures simply aren't that great when
compared to having more flexibility and the ability to pre-compile selective
statements as required.  More and more vendors are *adding* dynamic SQL
capabilities to their SP languages, not removing them.

--
Tim Young
Elevate Software
www.elevatesoft.com