| Subject | Re: [firebird-support] Set term gives Token unknown error |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-04-29T22:20:57Z |
At 02:58 AM 30/04/2008, Stevio wrote:
(and back again)
Your Delphi data access components sit between the client app and the API. They interpret your app language requests and send API function calls "across the wire" that contain those requests in the format that Firebird requires...and receive and interpret structures that the engine sends back across the wire to the API. On the server side the "Y-valve" is like a traffic cop, figuring out where stuff is coming from and where it has to go, so that the engine doesn't care whether the "wire" is a network, a local TCP/IP loopback, a local XNET connection, or whatever.
Lots of different things go across the wire, including SQL requests. If SQL requests are legal and correct, they get serviced. If you send illegal or incorrect requests as though they were SQL, you get exceptions. "SET TERM" is not an SQL statement. It is one of a set of local commands that you can use in scripts that you are going to process in isql.
Tools like Flamerobin and IB_SQL, that have script processors, know to filter out these isql commands and they know, for example, that a pair of SET TERM statements encloses a block of commands where the statement terminator is something other than a semi-colon. Any semi-colons inside that block will be terminators for code lines inside a "complex" DDL statement like CREATE/ALTER PROCEDURE/TRIGGER and the final END statement of that module.
^ heLen
>What does "across the wire" mean?Client app -> API -> wire -> Y-valve -> Firebird engine
(and back again)
Your Delphi data access components sit between the client app and the API. They interpret your app language requests and send API function calls "across the wire" that contain those requests in the format that Firebird requires...and receive and interpret structures that the engine sends back across the wire to the API. On the server side the "Y-valve" is like a traffic cop, figuring out where stuff is coming from and where it has to go, so that the engine doesn't care whether the "wire" is a network, a local TCP/IP loopback, a local XNET connection, or whatever.
Lots of different things go across the wire, including SQL requests. If SQL requests are legal and correct, they get serviced. If you send illegal or incorrect requests as though they were SQL, you get exceptions. "SET TERM" is not an SQL statement. It is one of a set of local commands that you can use in scripts that you are going to process in isql.
Tools like Flamerobin and IB_SQL, that have script processors, know to filter out these isql commands and they know, for example, that a pair of SET TERM statements encloses a block of commands where the statement terminator is something other than a semi-colon. Any semi-colons inside that block will be terminators for code lines inside a "complex" DDL statement like CREATE/ALTER PROCEDURE/TRIGGER and the final END statement of that module.
>Would you recommend FlameRobin above IB_SQL?The tools you finally choose depends entirely on your own needs and preferences. For me, those two, alongside isql, are *my* tools of choice. There are many other options to choose from - if you want to have that discussion, please take it to the firebird-tools list. Above all, try them out for yourself.
>Also, what would you recommend for books to help bring me up to date on andBesides The Firebird Book (and the supplements available from IBPhoenix) I would recommend "SQL for Dummies", the SECOND EDITION if you can get it. It's cheap and comprehensive and very approachable.
>improve my knowledge and understanding of Firebird
>(and any recommendations for books to bring me up to date on Delphi would be appreciated too, although off topic to this list)?Yes, off-topic to this list. Even if you don't buy from Amazon, visit their US and UK sites and look for the recommendation lists for Delphi. Pick the ones that pop up the most often and then go and read the reader reviews. Readers do a lot better job than the publishers of telling you about the pitch and content of technical books.
^ heLen