Misc.

doc/README.external_routines.txt

@@ -63,10 +63,10 @@ config example present below).
 
 When Firebird wants to load an external routine (function, procedure or trigger) into its metadata
 cache, it gets (if not already done for the database*) the external engine through the plugin
-external engine factory and ask it for the routine. The plugin used is the one referenced by the
+external engine factory and asks it for the routine. The plugin used is the one referenced by the
 attribute plugin_module of the external engine.
 
-* This is in Super-Server. In [Super-]Classic, different attachments to one database creates
+* This is in Super-Server. In [Super-]Classic, different attachments to one database create
 multiple metadata caches and hence multiple external engine instances.
 
 
@@ -93,8 +93,8 @@ the correspondent plugin_config tag. By default, UDR modules should be on <fbroo
 accordingly to its path attribute in <fbroot>/plugins/udr_engine.conf.
 
 The user library should include FirebirdUdr.h (or FirebirdUdrCpp.h) and link with the udr_engine
-library. Routines are easily defined and registered using some macros, but nothing prevent you of
+library. Routines are easily defined and registered using some macros, but nothing prevents you from
-doing things manually. A example routine library is implemented in examples/plugins, showing how to
+doing things manually. An example routine library is implemented in examples/plugins, showing how to
 write functions, selectable procedures and triggers. Also it shows how to interact with the current
 database through the ISC API.
 
@@ -102,6 +102,6 @@ The UDR routines state (i.e., member variables) are shared between multiple invo
 routine until it's unloaded from the metadata cache. But note that it isolates the instances per
 session, different from the raw interface that shares instances by multiple sessions in SuperServer.
 
-By default, UDR routines uses the same character set specified by the client. They can modify it
+By default, UDR routines use the same character set specified by the client. They can modify it
 overriding the getCharSet method. The chosen character set is valid for communication with the ISC
 library as well as the communications done through the FirebirdExternal API.

doc/sql.extensions/README.ddl_triggers.txt

@@ -104,7 +104,7 @@ DDL_TRIGGER context namespace:
 	procedures called by DDL triggers.
 	The DDL_TRIGGER context works like a stack. Before a DDL trigger is fired, it's pushed on that
 	stack the values relative to the executed command. After the trigger finishes, the value is
-	poped. So in the case of cascade DDL statements, when an user DDL command fires a DDL trigger
+	popped. So in the case of cascade DDL statements, when an user DDL command fires a DDL trigger
 	and this trigger executes another DDL command with EXECUTE STATEMENT, the values of DDL_TRIGGER
 	namespace are the ones relative to the command that fired the last DDL trigger on the call
 	stack.
@@ -157,7 +157,7 @@ set term ;!
 ----------------------------------------
 
 
-2) Implement handy-made DDL security. Only certainly users could run DDL commands.
+2) Implement hand-made DDL security. Only certainly users could run DDL commands.
 
 create exception e_access_denied 'Access denied';
 
@@ -247,7 +247,7 @@ commit;
 
 -- Test
 
--- This will be logged one time (as T1 did not exists, RECREATE acts as CREATE) with OK = Y.
+-- This will be logged one time (as T1 did not exist, RECREATE acts as CREATE) with OK = Y.
 recreate table t1 (
     n1 integer,
     n2 integer

doc/sql.extensions/README.packages.txt

@@ -65,12 +65,12 @@ Objectives:
       It's well know in programming world that having code grouped in some way (for example in
       namespaces, units or classes) is a good thing. With standard procedures and functions in the
       database this is not possible. It's possible to group them in different scripts files, but
-      two problems remains:
+      two problems remain:
       1) The grouping is not represented in the database metadata.
       2) They all participate in a flat namespace and all routines are callable by everyone (not
          talking about security permissions here).
     
-    - Facilitate dependency tracking between its internal routines and between others packaged and
+    - Facilitate dependency tracking between its internal routines and between other packaged and
       unpackaged routines.
 
       Firebird packages are divided in two pieces: a header (aka PACKAGE) and a body (aka
@@ -104,7 +104,7 @@ Objectives:
       defining package.
 
       All programming languages have the notion of routine scope. But without some form of grouping,
-      this is not possible. Firebird packages also works as Delphi units in this regard. If a
+      this is not possible. Firebird packages also work as Delphi units in this regard. If a
       routine is not declared on the package header (interface) and is implemented in the body
       (implementation), it becomes a private routine. A private routine can only be called from
       inside its package.
@@ -117,7 +117,7 @@ Syntax rules:
       procedures not declared.
 
 Notes:
-    - DROP PACKAGE drops the package body before drop its header.
+    - DROP PACKAGE drops the package body before dropping its header.
     - UDFs (DECLARE EXTERNAL FUNCTION) are currently not supported inside packages.
 
 Examples:

src/config/ConfObject.cpp

@@ -272,7 +272,7 @@ Firebird::string ConfObject::expand(const char* rawValue)
 		return temp;
 
 	// ASF: Do not try to expand relative filenames. It seems better to use $(this), or if necessary
-	// a new expansion variable. Also, this function is bugged and is returning incorrect values.
+	// a new expansion variable. Also, this function is buggy and is returning incorrect values.
 	// return PathName::expandFilename (temp);
 	return temp;
 }