[libgda] Correct spelling errors in documentation.
- From: Bas Driessen <basd src gnome org>
- To: svn-commits-list gnome org
- Cc:
- Subject: [libgda] Correct spelling errors in documentation.
- Date: Tue, 18 Aug 2009 09:27:24 +0000 (UTC)
commit f970f23ac197b3206f67a272456b84315d815920
Author: Bas Driessen <bas driessen xobas com>
Date: Tue Aug 18 19:25:25 2009 +1000
Correct spelling errors in documentation.
doc/C/gda-sql-manual.xml | 22 +++++-----
doc/C/gettingstarted.xml | 18 ++++----
doc/C/howto.xml | 12 +++---
doc/C/i_s_doc.xml | 6 +-
doc/C/information_schema.svg | 4 +-
doc/C/installation.xml | 6 +-
doc/C/libgda-4.0-docs.sgml | 50 ++++++++++++------------
doc/C/limitations.xml | 4 +-
doc/C/migration.xml | 2 +-
doc/C/migration2.xml | 18 ++++----
doc/C/packaging.xml | 10 ++--
doc/C/packaging_ui.xml | 6 +-
doc/C/prov-writing.xml | 34 ++++++++--------
doc/C/server-operation.xml | 2 +-
doc/C/store-meta-type.xml | 2 +-
doc/C/thread-wrapper.svg | 2 +-
doc/C/tmpl/gda-attributes-manager.sgml | 4 +-
doc/C/tmpl/gda-config.sgml | 2 +-
doc/C/tmpl/gda-connection-event.sgml | 2 +-
doc/C/tmpl/gda-connection.sgml | 4 +-
doc/C/tmpl/gda-data-handler.sgml | 2 +-
doc/C/tmpl/gda-data-model-bdb.sgml | 12 +-----
doc/C/tmpl/gda-data-model-dir.sgml | 2 +-
doc/C/tmpl/gda-data-model-import.sgml | 2 +-
doc/C/tmpl/gda-data-model.sgml | 2 +-
doc/C/tmpl/gda-data-proxy.sgml | 4 +-
doc/C/tmpl/gda-data-select.sgml | 2 +-
doc/C/tmpl/gda-meta-store.sgml | 2 +-
doc/C/tmpl/gda-meta-struct.sgml | 2 +-
doc/C/tmpl/gda-pstmt.sgml | 6 +-
doc/C/tmpl/gda-report-engine.sgml | 2 +-
doc/C/tmpl/gda-server-operation-sequences.sgml | 2 +-
doc/C/tmpl/gda-server-operation.sgml | 2 +-
doc/C/tmpl/gda-server-provider.sgml | 2 +-
doc/C/tmpl/gda-set.sgml | 2 +-
doc/C/tmpl/gda-sql-parser.sgml | 13 ++----
doc/C/tmpl/gda-sql-statement.sgml | 2 +-
doc/C/tmpl/gda-transaction-status.sgml | 2 +-
doc/C/tmpl/gda-tree-manager.sgml | 2 +-
doc/C/tmpl/gda-tree-mgr-label.sgml | 2 +-
doc/C/tmpl/gda-value.sgml | 2 +-
doc/C/tmpl/gda-vconnection-hub.sgml | 2 +-
doc/C/tmpl/gda-xa-transaction.sgml | 2 +-
doc/C/tmpl/provider-support-sql.sgml | 8 ++--
doc/C/tmpl/provider-support.sgml | 2 +-
doc/C/virtual.xml | 2 +-
46 files changed, 141 insertions(+), 154 deletions(-)
---
diff --git a/doc/C/gda-sql-manual.xml b/doc/C/gda-sql-manual.xml
index 98579fc..5fcea2b 100644
--- a/doc/C/gda-sql-manual.xml
+++ b/doc/C/gda-sql-manual.xml
@@ -7,7 +7,7 @@
</para>
<para>
- However, contrary to the programmed mentionned above, The &LIBGDA;'s console tool
+ However, contrary to the programmed mentioned above, The &LIBGDA;'s console tool
offers the same features and usage for any of the databases supported by &LIBGDA;.
For more information, consult the man page (<command>man gda-sql</command>).
</para>
@@ -30,9 +30,9 @@
<listitem><para>Allow one to define variables which can be referenced in any
SQL statement (using a common syntax)</para></listitem>
<listitem><para>One query buffer per connection to edit complex queries (uses a
- parametrable external editor)</para></listitem>
+ parameter-able external editor)</para></listitem>
<listitem><para>Easy command line editing and output using the Readline library and a
- (parametrable) pager</para></listitem>
+ (parameter-able) pager</para></listitem>
<listitem><para>Work on any platform on which &LIBGDA; has been ported to.</para></listitem>
<listitem><para>List, define or remove named data sources (DSN)</para></listitem>
<listitem><para>Import and export BLOBS (binary large objects) from and to local files</para></listitem>
@@ -96,7 +96,7 @@ MSAccess | Provider for Microsoft Access files | DB_NAME, |
before the tool exits</para></listitem>
<listitem><para>the <option>-o</option> option allows to specify a file to write the
output to</para></listitem>
- <listitem><para>the <option>-p</option> speficies that the tool should not ask for
+ <listitem><para>the <option>-p</option> specifies that the tool should not ask for
passwords when a username has been specified for a connection but no password has
been specified.</para></listitem>
<listitem><para>the <option>-s</option> requests the embedded HTTP server to be executed, listening on
@@ -342,7 +342,7 @@ cnc3>
<title>Meta data</title>
<para>
When a connection is opened for the first time, the tool get all the possible meta data associated to that connection (list of
- tables, table's columns and their constraints, views, etc). The meta data are refered to when the user wants for example
+ tables, table's columns and their constraints, views, etc). The meta data are referred to when the user wants for example
to list a table's attributes, or for command line completion.
</para>
<para>
@@ -481,7 +481,7 @@ cnc1>
<para>
Finally, the <command>.graph [TABLE1 [TABLE2...]]</command> will create a graph of all the tables (or
- only the tables mentionned as arguments). The graph creates a <application>GraphViz</application> file
+ only the tables mentioned as arguments). The graph creates a <application>GraphViz</application> file
named "graph.dot" which can then be processed with the GraphViz'<command>dot</command> command to
produce an image or a PDF file for example.
</para>
@@ -589,7 +589,7 @@ pg_sync_pg_auth_members | UPDATE | pg_auth_members
</chapter>
<chapter id="gda-sql-manual-icommands">
- <title>Detailled features</title>
+ <title>Detailed features</title>
<para>
This section explains in depth various aspects of the console tool.
</para>
@@ -598,9 +598,9 @@ pg_sync_pg_auth_members | UPDATE | pg_auth_members
<title>Query buffer</title>
<para>
Everytime an SQL command is entered, it is stored in the query buffer associated to the current connection.
- The query buffer can be edited using an external editor (which can be usefull for multi line SQL statements) using
+ The query buffer can be edited using an external editor (which can be useful for multi line SQL statements) using
the <command>.e</command> command. The query buffer can also be saved to a file and loaded back later using the
- <command>.qw</command> and <command>.qr</command> commands. To execute the SQL held in the current query byffer,
+ <command>.qw</command> and <command>.qr</command> commands. To execute the SQL held in the current query buffer,
use the <command>.g</command> command.
</para>
<para>
@@ -737,7 +737,7 @@ SalesTest>
</itemizedlist>
</para>
<para>
- Clients must first authenticate before they can use the features mentionned above; authentication is kept simple
+ Clients must first authenticate before they can use the features mentioned above; authentication is kept simple
as it consists of a string. By default the requested string is empty (eg. no real authentication is required), but
an authentication string can be specified when running the web server either with the <command>.http</command> command,
or the <option>-t</option> command line option.
@@ -755,7 +755,7 @@ SalesTest>
</para></listitem>
<listitem><para>The external editor used by the <command>.e</command> command is determined by the first value
present in the <envar>GDA_SQL_EDITOR</envar>, <envar>EDITOR</envar> or <envar>VISUAL</envar>
- environment variables (in that order), and defaults to "vi" undex Unix and "notepad.exe" under Windows.
+ environment variables (in that order), and defaults to "vi" under Unix and "notepad.exe" under Windows.
</para></listitem>
<listitem><para>The pager used when the data to display is more than one screen is determined by
the value of the <envar>PAGER</envar> environment variable and defaults to "more" if none is defined.
diff --git a/doc/C/gettingstarted.xml b/doc/C/gettingstarted.xml
index 0f83a89..d759a91 100644
--- a/doc/C/gettingstarted.xml
+++ b/doc/C/gettingstarted.xml
@@ -1,7 +1,7 @@
<chapter id="getting_started">
<title>Code examples</title>
<sect1 id="initializing">
- <title>Initialising</title>
+ <title>Initializing</title>
<para>
First of all you have to initialise the gda library, i.e. to call the
<link linkend="gda-init">gda_init ()</link> function, for example:
@@ -10,7 +10,7 @@
gda_init ();
</programlisting>
<para>
- After initialising you can work as usual or make &LIBGDA;
+ After initializing you can work as usual or make &LIBGDA;
</para>
<para>For example a basic program would look like:
<programlisting>
@@ -51,12 +51,12 @@ main (int argc, char **argv)
<sect1 id="connections">
<title>Connecting</title>
<para>
- &LIBGDA; allows data sources (DSN) to be defined and refered to by a unique name which contains all the
+ &LIBGDA; allows data sources (DSN) to be defined and referred to by a unique name which contains all the
required information to actually open a connection (except the name and password if they are required);
see the <link linkend="libgda-40-Configuration">Configuration section</link> for more information about
how to manage data sources. Of
course it's still possible to open a connection without having defined a DSN, in which case a <emphasis>connection
- string</emphasis> is used to specify all the parameters resuired to open a connection. For more information
+ string</emphasis> is used to specify all the parameters required to open a connection. For more information
about connection strings, see the <link linkend="gda-connection-open-from-string">gda_connection_open_from_string ()</link>'s documentation.
</para>
<para>
@@ -89,7 +89,7 @@ do_stuff () {
</para>
<para>
Closing the connection can be ordered using <link linkend="gda-connection-close">gda_connection_close ()</link>,
- or is automatically done when the connection object is destroyed (as is the case in the example abive when
+ or is automatically done when the connection object is destroyed (as is the case in the example above when
<link linkend="g-object-unref">g_object_unref()</link> is called with the connection as argument).
</para>
</sect1>
@@ -119,7 +119,7 @@ do_stuff () {
<para>The performances of the resulting application are not optimized because the database needs to parse the SQL
string each time and build its own internal representation of the statement, execute the statement using its
internal representation, then discard that internal representation. Using variables and reusing the same statement,
- the database only parses once the SQL statement, builds its internal representation, and reuses it everytime
+ the database only parses once the SQL statement, builds its internal representation, and reuses it every time
the statement is executed.
</para>
</listitem>
@@ -301,7 +301,7 @@ show_data_model (GdaDataModel *dm)
The <emphasis>transaction status</emphasis> of any connection can be obtained using
<link linkend="gda-connection-get-transaction-status">gda_connection_get_transaction_status ()</link>, which
returns a <link linkend="GdaTransactionStatus">GdaTransactionStatus's</link> object which can be interrogated. That
- object also makes it easy to keep up with the evolutions of the transaction status of the connection.
+ object also makes it easy to keep up with the evolution of the transaction status of the connection.
</para>
</sect1>
@@ -315,7 +315,7 @@ show_data_model (GdaDataModel *dm)
<listitem><para>GDA_CONNECTION_EVENT_NOTICE: for notices which are general purpose information</para></listitem>
<listitem><para>GDA_CONNECTION_EVENT_WARNING: for warnings</para></listitem>
<listitem><para>GDA_CONNECTION_EVENT_ERROR: for errors</para></listitem>
- <listitem><para>GDA_CONNECTION_EVENT_COMMAND: for SQL stataments which have been executed</para></listitem>
+ <listitem><para>GDA_CONNECTION_EVENT_COMMAND: for SQL statements which have been executed</para></listitem>
</itemizedlist>
</para>
<para>
@@ -376,7 +376,7 @@ p1000 | flowers | 1.990000
<sect1 id="ddl_example">
<title>DDL example</title>
<para>
- Ths following example illustrates (in a very simple way) how to use the
+ The following example illustrates (in a very simple way) how to use the
<link linkend="GdaServerOperation">GdaServerOperation</link> object to perform a CREATE TABLE query.
For more information about how &LIBGDA; handles DDL queries, see <link linkend="DDLIntro">the DDL introduction</link>.
The following code simply executes the equivalent of "CREATE TABLE products (id int PRIMARY KEY, product_name string NOT NULL);"
diff --git a/doc/C/howto.xml b/doc/C/howto.xml
index 1d88058..f4e586b 100644
--- a/doc/C/howto.xml
+++ b/doc/C/howto.xml
@@ -67,7 +67,7 @@ if (!gda_config_define_dsn (&dsn_info, &error)) {
Any SQL command in &LIBGDA; must be converted to a <link linkend="GdaStatement">GdaStatement</link> object
which is then executed; if the statement defines some variable (place holders), then variables binding
(assigning values to variables) is done at execution time. Each database provider (database
- <emphasis>driver</emphasis> or <emphasis>adaptator</emphasis>) can implement its own parser to
+ <emphasis>driver</emphasis> or <emphasis>adapter</emphasis>) can implement its own parser to
be able to parse its specific SQL dialect. Except for binding variables, and for reusability, the
<link linkend="GdaStatement">GdaStatement</link> object guarantees that it contains only one SQL statement
(it's not possible for it to contain several ones separated by a semicolon).
@@ -84,7 +84,7 @@ if (!gda_config_define_dsn (&dsn_info, &error)) {
<para>
<programlisting>
GdaSqlParser *parser;
-GdaStatament *stmt;
+GdaStatement *stmt;
GError *error = NULL;
parser = gda_connection_create_parser (cnc);
@@ -118,7 +118,7 @@ g_object_unref (stmt);
<title>Modify the result of a SELECT command</title>
<para>
The <link linkend="GdaDataSelect">GdaDataSelect</link> data model (which is the data model returned
- after the successfull execution of a SELECT statement) is by default read-only, but can be made writable
+ after the successful execution of a SELECT statement) is by default read-only, but can be made writable
after giving it information about:
<itemizedlist>
<listitem><para>how to identify a single row in the modified table
@@ -209,14 +209,14 @@ gda_value_free (value);
<para>
INSERT, UPDATE or DELETE are treated in the same way as the SELECT command (see the
<link linkend="howto-exec-select">HOWTO</link> about executing
- a SELECT command), except that the function to execute the command is different because the retuned value
+ a SELECT command), except that the function to execute the command is different because the returned value
is not a data model but a success/failure value.
</para>
<para>
The following codes illustrates parsing and executing an UPDATE statement:
<programlisting>
GdaSqlParser *parser;
-GdaStatament *stmt;
+GdaStatement *stmt;
GError *error = NULL;
parser = gda_connection_create_parser (cnc);
@@ -376,7 +376,7 @@ else {
<listitem><para>Knowing the information schema's structure (tables and views) used,
run some SELECT commands on the
<link linkend="GdaMetaStore">GdaMetaStore</link> object's internal connection: this solution is the most
- powerfull but requires some knowledge of the information schema's structure, and the data
+ powerful but requires some knowledge of the information schema's structure, and the data
is not easy to use.</para></listitem>
<listitem><para>Use a <link linkend="GdaMetaStruct">GdaMetaStruct</link> object which
<emphasis>exports</emphasis> the meta data as a dynamic tree of pre-defined data structures,
diff --git a/doc/C/i_s_doc.xml b/doc/C/i_s_doc.xml
index 472fc28..48a7627 100644
--- a/doc/C/i_s_doc.xml
+++ b/doc/C/i_s_doc.xml
@@ -320,8 +320,8 @@ UNION
SELECT domain_short_name, domain_gtype, domain_full_name, domain_comments, domain_internal, NULL,
domain_catalog, domain_schema, domain_name , NULL, NULL, NULL FROM _domains</programlisting></para>
</sect3>
- <sect3 id="is:_detailled_fk">
- <title>_detailled_fk view</title>
+ <sect3 id="is:_detailed_fk">
+ <title>_detailed_fk view</title>
<para>For each foreign key constraint, lists all the tables' columns involved and the constraint name</para>
<para>Definition is:<programlisting width="80">SELECT rc.table_catalog as fk_table_catalog, rc.table_schema as fk_table_schema, rc.table_name as fk_table_name, kc1.column_name as fk_column,
rc.ref_table_catalog as ref_table_catalog, rc.ref_table_schema as ref_table_schema, rc.ref_table_name as ref_table_name, kc2.column_name as ref_column,
@@ -333,4 +333,4 @@ SELECT domain_short_name, domain_gtype, domain_full_name, domain_comments, domai
ORDER BY rc.table_catalog, rc.table_schema, rc.table_name, kc1.ordinal_position
</programlisting></para>
</sect3>
-</sect2>
\ No newline at end of file
+</sect2>
diff --git a/doc/C/information_schema.svg b/doc/C/information_schema.svg
index 1a99ff3..7298c2b 100644
--- a/doc/C/information_schema.svg
+++ b/doc/C/information_schema.svg
@@ -2780,7 +2780,7 @@
id="node59"
transform="matrix(1.33333,0,0,1.33333,-2115.9054,1960.8192)">
<title
- id="title1164">main.main._detailled_fk</title>
+ id="title1164">main.main._detailed_fk</title>
<polygon
id="polygon1166"
points="2254,-203 2254,-223 2370,-223 2370,-203 2254,-203 "
@@ -2789,7 +2789,7 @@
id="text1168"
style="font-size:14.17500019px;text-anchor:middle;font-family:Nimbus Roman No9 L"
y="-208.33299"
- x="2312">_detailled_fk</text>
+ x="2312">_detailed_fk</text>
<polygon
id="polygon1170"
points="2254,-203 2254,-223 2370,-223 2370,-203 2254,-203 "
diff --git a/doc/C/installation.xml b/doc/C/installation.xml
index 615624f..dc7bb5d 100644
--- a/doc/C/installation.xml
+++ b/doc/C/installation.xml
@@ -4,7 +4,7 @@
<title>Getting the library</title>
<para>
The &LIBGDA; library is bundled with some Linux distributions, so for these distributions, installing
- can be done using the distribution speficic tools.
+ can be done using the distribution specific tools.
</para>
<para>
Also &LIBGDA;'s sources are available for download from the
@@ -198,13 +198,13 @@
Any connection to a database can be done either using a pre-defined data source, or using a
connection string: using a data source (DSN) allows one to <emphasis>name</emphasis> connections
and define them once, whereas using connection strings allows programs to be more
- independant of any &LIBGDA; configuration. Anyway, defining a DSN involves defining the same
+ independent of any &LIBGDA; configuration. Anyway, defining a DSN involves defining the same
parameters as for a connection string.
</para>
<para>
A connection string is a semi-colon delimited list of named parameters
(as <![CDATA[<param1_name>=<param1_value>;<param2_name>=<param2_value>...]]>), the parameters
- being specific to each database provider (the two commands mentionned above also list all the
+ being specific to each database provider (the two commands mentioned above also list all the
parameters for each provider).
</para>
<para>
diff --git a/doc/C/libgda-4.0-docs.sgml b/doc/C/libgda-4.0-docs.sgml
index 173f3dd..aa5c997 100644
--- a/doc/C/libgda-4.0-docs.sgml
+++ b/doc/C/libgda-4.0-docs.sgml
@@ -267,7 +267,7 @@
operating system on which the client is running.
</para>
<para>
- &SQL; itself is also not standardised enough, so that source
+ &SQL; itself is also not standardized enough, so that source
compatibility can not be assured for all database servers. And for some
sort of servers, &SQL; is not even feasible (think about &LDAP;).
</para>
@@ -364,7 +364,7 @@
<para>Firebird: compiles, needs testing;</para>
</listitem>
<listitem>
- <para>IBM DB2: compiles but is not useable, work in progress;</para>
+ <para>IBM DB2: compiles but is not usable, work in progress;</para>
</listitem>
<listitem>
<para>Microsoft SQL Server and Sybase using the <ulink url="http://www.freetds.org/";>FreeTDS</ulink> library:
@@ -374,19 +374,19 @@
<para>mSQL: compiles, needs testing;</para>
</listitem>
<listitem>
- <para>MySQL: fully functionnal;</para>
+ <para>MySQL: fully functional;</para>
</listitem>
<listitem>
<para>ODBC: seems to work correctly, needs testing;</para>
</listitem>
<listitem>
- <para>Oracle: work is progress, useable;</para>
+ <para>Oracle: work is progress, usable;</para>
</listitem>
<listitem>
- <para>PostgreSQL: fully functionnal;</para>
+ <para>PostgreSQL: fully functional;</para>
</listitem>
<listitem>
- <para>SQLite: fully functionnal;</para>
+ <para>SQLite: fully functional;</para>
</listitem>
<listitem>
<para>Sybase: compiles, needs testing;</para>
@@ -478,7 +478,7 @@
<para>
As a result, &LIBGDA; has to be the least intrusive possible when the user wants to execute an SQL statement,
and lets the database being accessed apply its own rules. However &LIBGDA; features meta data information
- retreival (getting the list of tables, views,...) and there some representation conventions have been fixed,
+ retrieval (getting the list of tables, views,...) and there some representation conventions have been fixed,
see the <link linkend="information_schema:sql_identifiers">meta data section about SQL identifiers</link>
for more information.
</para>
@@ -531,7 +531,7 @@
<listitem>
<para>GDA_SHOW_PROVIDER_LOADING_ERROR: if set, then in case a provider fails to be loaded (usually because
it requires a library which can't be found) &LIBGDA; will display a warning message. This variable
- is usefull to debug the absence of a provider at runtime</para>
+ is useful to debug the absence of a provider at runtime</para>
</listitem>
<listitem>
<para>GDA_DATA_MODEL_DUMP_TITLE: if set, then <link linkend="gda-data-model-dump">gda_data_model_dump()</link>
@@ -589,7 +589,7 @@
</para>
<para>
As each database implements its own SQL variant (all variants more or less close to the SQL92 or SQL99 standards), the
- &LIBGDA; library allows one to use either a generic SQL parser, or a parser provided by each database adaptator (database
+ &LIBGDA; library allows one to use either a generic SQL parser, or a parser provided by each database adapter (database
provider), through the <link linkend="gda-connection-create-parser">gda_connection_create_parser()</link> method.
</para>
<para>
@@ -653,7 +653,7 @@
<para>
The GdaSet object also makes some computations to group value holders which are
constrained by values in the same GdaDataModel (it makes it easy to use value holders
- which are not really independant).
+ which are not really independent).
</para>
</listitem>
<listitem>
@@ -661,7 +661,7 @@
column have the same type, and all the data in each row have the same semantic meaning.
&LIBGDA; uses the <link linkend="GdaDataModel">GdaDataModel</link>
objects to actually hold the data (note that this is actually an interface which has
- sevaral implementations depending on the real data organization in the data model).</para>
+ several implementations depending on the real data organization in the data model).</para>
<para>Note that depending on the real implementation, access to the data can be random or
done using an iterator, and that the data model can be read-only or modifiable.</para>
</listitem>
@@ -704,7 +704,7 @@
<para>
A tree is represented by a
unique <link linkend="GdaTree">GdaTree</link> object,
- in which each node is represented by a <link linkend="GdaTreeNode">GdaTreeNode</link> object. As mentionned previously, any
+ in which each node is represented by a <link linkend="GdaTreeNode">GdaTreeNode</link> object. As mentioned previously, any
<link linkend="GdaTreeNode">GdaTreeNode</link> in a <link linkend="GdaTree">GdaTree</link> is created (and destroyed)
by a <link linkend="GdaTreeManager">GdaTreeManager</link> object: the nodes hierarchy itself is
represented by a hierarchy of <link linkend="GdaTreeManager">GdaTreeManager</link> objects
@@ -808,7 +808,7 @@
the <link linkend="GdaTreeMgrTables">GdaTreeMgrTables</link> manager, uses
<link linkend="gda-tree-node-fetch-attribute">gda_tree_node_fetch_attribute()</link> to get the
"schema" attribute from the node below which it has to create children nodes. If the attribute exists, it
- then creates a node for each table in the mentionned schema, and otherwise creates a node for each table
+ then creates a node for each table in the mentioned schema, and otherwise creates a node for each table
visible by default.
</para>
<para>
@@ -859,19 +859,19 @@ g_object_unref (tree);
A single piece of data can have several representations
depending on its usage: a string representation, an SQL representation and of course a
<link linkend="GValue">GValue</link> representation. Conversions from one representation to
- the other is DBMS dependant as each database can have its own SQL representation rules. The
+ the other is DBMS dependent as each database can have its own SQL representation rules. The
<link linkend="GdaDataHandler">GdaDataHandler</link> object's purpose is to do all these conversions in a easy way.
- Except when mentionned otherwise, conversions take into account locale settings and DBMS specifications.
+ Except when mentioned otherwise, conversions take into account locale settings and DBMS specifications.
</para>
<para>
- To convert a data, one needs to instanciate a new data handler from one of the many classes which implement this interface, or
+ To convert a data, one needs to instantiate a new data handler from one of the many classes which implement this interface, or
better to get a pointer to a <link linkend="GdaDataHandler">GdaDataHandler</link> object (no
need to unref() it after usage, data handler objects are stateless), and so to obtain such a pointer one can:
<itemizedlist>
<listitem>
<para>Use the <link linkend="gda-get-default-handler">gda_get_default_handler()</link>: the returned data handler
is a generic one and should not be used to convert data to use with any connection, but only to have
- a portable way of storing and loading data in a locale independant fashion (for serialization purposes).</para>
+ a portable way of storing and loading data in a locale independent fashion (for serialization purposes).</para>
</listitem>
<listitem>
<para>Ask a <link linkend="GdaServerProvider">GdaServerProvider</link> object for one using the
@@ -1021,7 +1021,7 @@ g_object_unref (store);
In very simple cases, when the data to store is made of named values, the easiest way is to use the
<link linkend="gda-meta-store-set-attribute-value">gda_meta_store_set_attribute_value()</link> and
<link linkend="gda-meta-store-get-attribute-value">gda_meta_store_get_attribute_value()</link> methods
- where the values are stored and retreived as strings.
+ where the values are stored and retrieved as strings.
</para>
</sect3>
<sect3>
@@ -1097,7 +1097,7 @@ g_object_unref (store);
<link linkend="is:_all_types">"_all_types"</link> view as a convenience.
</para>
<para>
- The impact of that data types' hierarchy is that everytime a data type is referenced (from a table's column
+ The impact of that data types' hierarchy is that every time a data type is referenced (from a table's column
definition for example), there will be two attributes for the data type: one named
<parameter>data_type</parameter> which, if not NULL, refers to a data type listed in the
<link linkend="is:_all_types">"_all_types"</link> view (thus a built in, domain or user defined data type), and
@@ -1113,7 +1113,7 @@ g_object_unref (store);
<link linkend="is:_element_types">"_element_types"</link> table.
</para>
<para>
- The following diagram illustrates the data types representation and how ther are refered from table's columns,
+ The following diagram illustrates the data types representation and how they are referred from table's columns,
domains, and other database objects which refer to a data type:
<mediaobject>
<imageobject role="html">
@@ -1229,7 +1229,7 @@ g_object_unref (store);
<chapter id="libgda-tools-introduction">
<title>Introduction</title>
<para>
- &LIBGDA; offers several command line tools to help disgnose and resolve problems. All the
+ &LIBGDA; offers several command line tools to help diagnose and resolve problems. All the
provided tools can be run with the "--help" command line argument to give an online help
and description. Also, some environment variables can be set to control the output for some of
the tools, see <link linkend="libgda_env_variables">&LIBGDA;'s environment variables</link> section
@@ -1265,7 +1265,7 @@ DSN | Provider | Description | Connection string | Username
Sales | PostgreSQL | Sales | DB_NAME=sales |
[...]
</programlisting>
- To run an interractive session, just specify a DSN or a connection string using
+ To run an interactive session, just specify a DSN or a connection string using
the "<provider>://<connection string>"
format (such as for example "Firebird://DATABASE=/path/to/dbfile.fdb"), or set
the GDA_SQL_CNC environment variable to contain that string, and run the command without any argument,
@@ -1353,7 +1353,7 @@ c0> ]]>
<title>&gda-list-config;</title>
<para>
The &gda-list-config; tool simply lists all the declared data sources, and all the installed
- providers, giving some other usefull information as well for each. This tool has no option.
+ providers, giving some other useful information as well for each. This tool has no option.
</para>
<para>
An example output will be:
@@ -1567,7 +1567,7 @@ g_object_unref (eng);
</sect1>
</gda_report_section>
</article>]]></programlisting>
- For a more detailled example, have a look at the <filename class="directory">samples/Report</filename> of &LIBGDA;'s
+ For a more detailed example, have a look at the <filename class="directory">samples/Report</filename> of &LIBGDA;'s
sources.
</para>
</chapter>
@@ -1612,7 +1612,7 @@ g_object_unref (eng);
virtual methods.
</para>
<para>
- Database provider objects are generally instanciated once by the &LIBGDA; framework and can be used several
+ Database provider objects are generally instantiated once by the &LIBGDA; framework and can be used several
times to open and work on connections to several databases of the same type.
</para>
<para>
diff --git a/doc/C/limitations.xml b/doc/C/limitations.xml
index 99faf00..f087436 100644
--- a/doc/C/limitations.xml
+++ b/doc/C/limitations.xml
@@ -7,7 +7,7 @@
<sect2 id="threads"><title>Multi threaded environment</title>
<para>&LIBGDA; is not thread safe. However it supports working with threads as long as any object
(except otherwise stated) created by the API is used by one single thread (that is there is no
- situation when two threads try to acces the same object at the same time). Exceptions are:
+ situation when two threads try to access the same object at the same time). Exceptions are:
<itemizedlist>
<listitem><para>&LIBGDA;'s <link linkend="init_config">configuration</link> can be accessed from any thread</para></listitem>
<listitem><para>Any object which implements the <link linkend="GdaLockable">GdaLockable</link> interface
@@ -55,7 +55,7 @@
<para>
The following limitations apply to Oracle databases accessed via Libgda:
<itemizedlist>
- <listitem><para>At the moment tables' fields shema information retreival is very slow, so as a work around, use a dictionary
+ <listitem><para>At the moment tables' fields schema information retrieval is very slow, so as a work around, use a dictionary
to store the database schema and do incremental updates on modified/created tables.</para></listitem>
</itemizedlist>
</para>
diff --git a/doc/C/migration.xml b/doc/C/migration.xml
index 25dfcc7..f5e38d7 100644
--- a/doc/C/migration.xml
+++ b/doc/C/migration.xml
@@ -21,7 +21,7 @@
<para> The following UML schema shows the various implementations of the <classname>GdaDataModel</classname>
interface and what they are for. Note that the
- <classname>GdaDataModelRow</classname> should not be instanciated directly but either
+ <classname>GdaDataModelRow</classname> should not be instantiated directly but either
used as a base class, or used through its children classes.
</para>
<para>
diff --git a/doc/C/migration2.xml b/doc/C/migration2.xml
index 33382f3..9db3d90 100644
--- a/doc/C/migration2.xml
+++ b/doc/C/migration2.xml
@@ -4,9 +4,9 @@
<para>Version 4.0 of &LIBGDA; is a major rework of the library for the following benefits:
<itemizedlist>
<listitem><para>easier to understand and to use API, with less strange path usage (which were inherited
- from modifications above modifications where no global coherence was adressed)</para></listitem>
+ from modifications above modifications where no global coherence was addressed)</para></listitem>
<listitem><para>reduce the size of the library (now 1.3M compared to 1.7M once stripped) and the number of symbols
- (845 compared to 1420) and have less complicated and thus more maintanable code (190 files compared to 250).
+ (845 compared to 1420) and have less complicated and thus more maintainable code (190 files compared to 250).
</para></listitem>
<listitem><para>removal of the GdaClient object from which connections were created: this object did not offer
any significant features and made the API more difficult to use</para></listitem>
@@ -22,7 +22,7 @@
</sect1>
<sect1><title>New unique parser</title>
- <para>Previous &LIBGDA; versions had several builtin parsers relying on Lex/Yacc (or Flex/Bison) to analyse SQL with
+ <para>Previous &LIBGDA; versions had several builtin parsers relying on Lex/Yacc (or Flex/Bison) to analyze SQL with
the following limitations:
<itemizedlist>
<listitem><para>not all the SELECT, INSERT, DELETE and UPDATE constructions were recognized</para></listitem>
@@ -56,7 +56,7 @@
internal structures from it (before discarding the XML tree) which was both CPU and memory intensive. Memory was
also wasted as most of the time not all the dictionary would be exploited. The new
<link linkend="GdaMetaStore">GdaMetaStore</link> object relies on a database (an SQLite file by default) to store its data
- which solves the problems mentionned above.</para>
+ which solves the problems mentioned above.</para>
<para>It was difficult for applications to add their own data in the dictionary (the API existed but was difficult to understand
and use), this has been solved by allowing applications to create DBMS objects into the
<link linkend="GdaMetaStore">GdaMetaStore</link>'s associated database.</para>
@@ -91,13 +91,13 @@
&LIBGDA;'s reports API has not changed, but the syntax of the XML nodes specific to &LIBGDA; (those nodes are
replaced by contents when the report is generated) has changed:
<itemizedlist>
- <listitem><para>The parameter name to acces a data model's column name by its name
+ <listitem><para>The parameter name to access a data model's column name by its name
is now <query_name>|@<column_name>
instead of <query_name>/@<column_name></para></listitem>
- <listitem><para>The parameter name to acces a data model's column name by its index
+ <listitem><para>The parameter name to access a data model's column name by its index
is now <query_name>|#<column_index>
instead of <query_name>/#<column_index></para></listitem>
- <listitem><para>The parameter name to acces the total number of rows of a data model is now
+ <listitem><para>The parameter name to access the total number of rows of a data model is now
<query_name>|?nrows instead of <query_name>/%nrows</para></listitem>
</itemizedlist>
</para>
@@ -119,7 +119,7 @@
<itemizedlist>
<listitem><para>Data sources and installed providers are now handled using the
<link linkend="GdaConfig">GdaConfig</link> object, with the particularity that there can only be one
- such object instanciated per program.</para></listitem>
+ such object instantiated per program.</para></listitem>
<listitem><para>The GDA_DSN_LIST_IN_MEMORY environment variable which , if set, prevented &LIBGDA; from
writing the list of defined data sources to a file has been removed. To obtain the same result,
one must force the creation of the unique <link linkend="GdaConfig">GdaConfig</link> object with
@@ -146,7 +146,7 @@
<link linkend="gda-connection-open-from-string">gda_connection_open_from_string () depending
on how the connection is defined</link></para></listitem>
<listitem><para>Upon opening a connection, the <parameter>username</parameter> and <parameter>password</parameter>
- arguments have heen replaced by a more flexible arguments passing mechanism where providers can specify
+ arguments have been replaced by a more flexible arguments passing mechanism where providers can specify
what authorization parameters they use</para></listitem>
<listitem><para>gda_server_provider_get_last_insert_id() has been removed in favor of the "last_insert_row" argument
of the <link linkend="gda-connection-statement-execute">gda_connection_statement_execute ()</link> and
diff --git a/doc/C/packaging.xml b/doc/C/packaging.xml
index 2f64ac1..6bb632b 100644
--- a/doc/C/packaging.xml
+++ b/doc/C/packaging.xml
@@ -82,7 +82,7 @@
</programlisting>
</para>
<para>
- This component should be made dependant on the core libraries &LIBGDA; depends on such as GLib, LibXML and LibXSLT.
+ This component should be made dependent on the core libraries &LIBGDA; depends on such as GLib, LibXML and LibXSLT.
Also, if &LIBGDA; was compiled using a system installed SQLite, then a dependency also needs to be added to SQLite
(otherwise &LIBGDA; uses its own embedded version of SQLite, and no dependency needs to be defined on SQLite).
</para>
@@ -95,7 +95,7 @@
<sect1>
<title>Tools</title>
<para>
- &LIBGDA;'s offers several tools, the most usefull being an SQL console which allows one to issue SQL statement
+ &LIBGDA;'s offers several tools, the most useful being an SQL console which allows one to issue SQL statement
from the command line. This component has the following files:
<programlisting>
.
@@ -126,7 +126,7 @@
</programlisting>
</para>
<para>
- This component should be made dependant on the runtime component.
+ This component should be made dependent on the runtime component.
</para>
</sect1>
@@ -169,7 +169,7 @@
</programlisting>
</para>
<para>
- This kind of component should be made dependant on the database's library which is used,
+ This kind of component should be made dependent on the database's library which is used,
such as LibPQ for PostgreSQL, and also on &LIBGDA;'s runtime component.
</para>
</sect2>
@@ -203,7 +203,7 @@
</programlisting>
</para>
<para>
- This component should be made dependant on the Java virtual machine.
+ This component should be made dependent on the Java virtual machine.
</para>
</sect2>
</sect1>
diff --git a/doc/C/packaging_ui.xml b/doc/C/packaging_ui.xml
index aedeb53..4cb3da6 100644
--- a/doc/C/packaging_ui.xml
+++ b/doc/C/packaging_ui.xml
@@ -3,7 +3,7 @@
<para>
&LIBGDA; UI extension builds on top of &LIBGDA; and GTK+ to provide some graphical
widgets, a control center (to manage DSN and list installed providers) and a
- browser program to analyse the contents of a database.
+ browser program to analyze the contents of a database.
</para>
<sect1>
<title>Overview of the components</title>
@@ -68,7 +68,7 @@
</programlisting>
</para>
<para>
- This component should be made dependant on the &LIBGDA;'s runtime component.
+ This component should be made dependent on the &LIBGDA;'s runtime component.
</para>
</sect1>
@@ -110,7 +110,7 @@
</programlisting>
</para>
<para>
- This component should be made dependant on the runtime component above.
+ This component should be made dependent on the runtime component above.
</para>
</sect1>
diff --git a/doc/C/prov-writing.xml b/doc/C/prov-writing.xml
index ff1cca5..a6bfbc9 100644
--- a/doc/C/prov-writing.xml
+++ b/doc/C/prov-writing.xml
@@ -50,7 +50,7 @@
<sect1>
<title>Multi threaded environment</title>
<para>
- Each database provider should be useable in a multi threaded environment, even if they impose some restrictions
+ Each database provider should be usable in a multi threaded environment, even if they impose some restrictions
as to how they can be used in such an environment. The &LIBGDA;'s framework provides some locking mechanism which
is:
<itemizedlist>
@@ -117,7 +117,7 @@
virtual providers.
</para>
<para>
- The connection specific data for the database API can be retreived using the
+ The connection specific data for the database API can be retrieved using the
<link linkend="gda-connection-internal-get-provider-data">gda_connection_internal_get_provider_data()</link> method.
</para>
</sect2>
@@ -233,7 +233,7 @@
<sect2>
<title>create_parser()</title>
<para>
- This method instanciates a <link linkend="GdaSqlParser">GdaSqlParser</link> object which is
+ This method instantiates a <link linkend="GdaSqlParser">GdaSqlParser</link> object which is
adapted to the database's specific SQL dialect. If the provider does not implement its own parser,
then this method should not be implemented.
</para>
@@ -302,7 +302,7 @@
<title>get_data_handler()</title>
<para>
This method returns a <link linkend="GdaDataHandler">GdaDataHandler</link> for the requested data type. It should
- only instanciate each <link linkend="GdaDataHandler">GdaDataHandler</link> once and reuse it if the same request happens
+ only instantiate each <link linkend="GdaDataHandler">GdaDataHandler</link> once and reuse it if the same request happens
(the returned object will not be modified).
</para>
<para>
@@ -377,7 +377,7 @@ gboolean (*tables_views) (GdaServerProvider *, GdaConnection *, GdaMetaStore *,
<sect2>
<title>Important note about SQL identifiers</title>
<para>
- As mentionned in the <link linkend="information_schema:sql_identifiers">SQL identifiers</link> section,
+ As mentioned in the <link linkend="information_schema:sql_identifiers">SQL identifiers</link> section,
any SQL identifier in the meta store is represented either:
<itemizedlist>
<listitem><para>between double quotes if the SQL identifier is case sensitive</para></listitem>
@@ -403,7 +403,7 @@ gboolean (*tables_views) (GdaServerProvider *, GdaConnection *, GdaMetaStore *,
Also note that the extra arguments for each virtual method listed below, when they are present
and when they represent an SQL identifier, will be represented:
<itemizedlist>
- <listitem><para>for case insitive SQL identifiers: using all lower or all upper case (depending on the setting
+ <listitem><para>for case insensitive SQL identifiers: using all lower or all upper case (depending on the setting
set using <link linkend="gda-meta-store-set-identifiers-style">gda_meta_store_set_identifiers_style()</link>
</para></listitem>
<listitem><para>for case sensitive SQL identifiers: without the double quotes, but possibily with
@@ -424,7 +424,7 @@ gboolean (*tables_views) (GdaServerProvider *, GdaConnection *, GdaMetaStore *,
and passing a function which determines if a specific string is a reserved keyword. The usage of
this function is similar to the usage of the
<link linkend="gda-meta-store-set-identifiers-style">gda_meta_store_set_identifiers_style()</link>
- mentionned above.
+ mentioned above.
</para>
<para>
Writing a function which tests if a string is a reserved keyword is a non complicated but error
@@ -521,7 +521,7 @@ gboolean (*constraints_tab) (GdaServerProvider *, GdaConnection *, GdaMetaStore
</programlisting>
This method must update the contents of the <link linkend="is:_table_constraints">"_table_constraints"</link>
table which lists all the
- constraints (primary key, foreing key, unique or check cnstraints) for each table.
+ constraints (primary key, foreign key, unique or check constraints) for each table.
</para>
</sect2>
@@ -538,7 +538,7 @@ gboolean (*constraints_ref) (GdaServerProvider *, GdaConnection *, GdaMetaStore
</programlisting>
This method must update the contents of the
<link linkend="is:_referential_constraints">"_referential_constraints"</link> table which lists all the
- refetential constraints (which are also listed in the
+ referential constraints (which are also listed in the
<link linkend="is:_table_constraints">"_table_constraints"</link> table).
</para>
</sect2>
@@ -597,7 +597,7 @@ gboolean (*key_columns) (GdaServerProvider *, GdaConnection *, GdaMetaStore *,
</para>
<para>
The data model represents each row in a separate <link linkend="GdaRow">GdaRow</link> object, and virtual
- methods to retreive rows have to return new (and correctly initialized) objects of that class. The referencing
+ methods to retrieve rows have to return new (and correctly initialized) objects of that class. The referencing
of these new objects is left up to the implementation which:
<itemizedlist>
<listitem>
@@ -615,8 +615,8 @@ gboolean (*key_columns) (GdaServerProvider *, GdaConnection *, GdaMetaStore *,
enable to "cache" some rows and discard some when memory is needed</para>
</listitem>
</itemizedlist>
- Note that the methods mentionned in the 1st and 3rd items should be reserved for random data access mode,
- and that cursor based access mode should implement the method mentionned in th 2nd item.
+ Note that the methods mentioned in the 1st and 3rd items should be reserved for random data access mode,
+ and that cursor based access mode should implement the method mentioned in th 2nd item.
</para>
<sect2>
<title>fetch_nb_rows()</title>
@@ -682,7 +682,7 @@ gboolean (*key_columns) (GdaServerProvider *, GdaConnection *, GdaMetaStore *,
<para>
Blobs are a special feature of databases because they allow one to access the contents of a "cell" from the
API without using SQL (usually no SQL can be used to manipulate a blob's contents: an SQL statement is used to
- create, delete or retreive a blob, but the contents is accessed through the API).
+ create, delete or retrieve a blob, but the contents is accessed through the API).
</para>
<para>
&LIBGDA; encapsulates all blob operations in objects which must be implemented by each provider if they want to support
@@ -845,9 +845,9 @@ gboolean (*key_columns) (GdaServerProvider *, GdaConnection *, GdaMetaStore *,
<para>
The tokenizer (AKA lexer) generates values identified by the "L_" prefix (for example "L_BEGIN"). Because
the GdaSqlParser object uses the same lexer with at least two different parsers (namely the parser and delimiter
- mentionned earlier), and because the Lemon parser generator generates its own value identifiers for tokens, there
+ mentioned earlier), and because the Lemon parser generator generates its own value identifiers for tokens, there
is a conversion step (the "converter" block in the diagram) which converts the "L_" prefixed tokens with the ones
- useable by each parser (both converters are defined as arrays in the <filename>token_types.h</filename> file.
+ usable by each parser (both converters are defined as arrays in the <filename>token_types.h</filename> file.
</para>
</sect2>
<sect2>
@@ -910,7 +910,7 @@ gboolean (*key_columns) (GdaServerProvider *, GdaConnection *, GdaMetaStore *,
in <filename class="directory">providers/skel-implementation</filename> propose the following files layout (some of the files
are not required for virtual providers).
</para>
- <para> Of course this files layout is not required, but make it easy for maintenance. In the folloing list,
+ <para> Of course this files layout is not required, but make it easy for maintenance. In the following list,
the filenames here are the one for the "Capi" provider, and each provider should rename them:
<itemizedlist>
<listitem><para><filename>gda-capi.h</filename>: contains the provider name, the include files necessary to use the API and the
@@ -1003,7 +1003,7 @@ gboolean (*key_columns) (GdaServerProvider *, GdaConnection *, GdaMetaStore *,
</sect2>
<sect2>
<title>plugin_create_provider()</title>
- <para>This function actually instanciates a provider object and returns it.</para>
+ <para>This function actually instantiates a provider object and returns it.</para>
</sect2>
</sect1>
diff --git a/doc/C/server-operation.xml b/doc/C/server-operation.xml
index d2b55a8..65caf92 100644
--- a/doc/C/server-operation.xml
+++ b/doc/C/server-operation.xml
@@ -20,7 +20,7 @@
operation. For example to create a table, the required information will be the table name and the description of its
columns, and the optional information might be the schema in which to create the table for a PostgreSQL provider.</para>
<para>
- Additionnally some options can be passed when using that function in the form of named parameters, see <link linkend="gda-server-op-information-std">this section</link> for more information.
+ Additionally some options can be passed when using that function in the form of named parameters, see <link linkend="gda-server-op-information-std">this section</link> for more information.
</para>
</listitem>
<listitem>
diff --git a/doc/C/store-meta-type.xml b/doc/C/store-meta-type.xml
index 9b66272..c03a1d4 100644
--- a/doc/C/store-meta-type.xml
+++ b/doc/C/store-meta-type.xml
@@ -3,7 +3,7 @@
<para>
The <link linkend="gda-connection-get-meta-store-data">gda_connection_get_meta_store_data()</link> method allows
one to get the meta-data information about a database such as its structure (schema). The following table describes
- the actual data retreived by each <link linkend="GdaConnectionMetaType">GdaConnectionMetaType</link> type of request.
+ the actual data retrieved by each <link linkend="GdaConnectionMetaType">GdaConnectionMetaType</link> type of request.
</para>
<sect2 id="GdaConnectionMetaTypeGDA_CONNECTION_META_NAMESPACES">
diff --git a/doc/C/thread-wrapper.svg b/doc/C/thread-wrapper.svg
index 88857cf..117f938 100644
--- a/doc/C/thread-wrapper.svg
+++ b/doc/C/thread-wrapper.svg
@@ -650,7 +650,7 @@
sodipodi:role="line"
x="-54.150032"
y="253.51823"
- id="tspan6496">analysed by the user thread</tspan></text>
+ id="tspan6496">analyzed by the user thread</tspan></text>
<g
id="g3261"
transform="translate(-208.5965,124.24876)"
diff --git a/doc/C/tmpl/gda-attributes-manager.sgml b/doc/C/tmpl/gda-attributes-manager.sgml
index 2d9f0a9..a9ecdba 100644
--- a/doc/C/tmpl/gda-attributes-manager.sgml
+++ b/doc/C/tmpl/gda-attributes-manager.sgml
@@ -6,8 +6,8 @@ Manager for lists of attributes
<!-- ##### SECTION Long_Description ##### -->
<para>
- The #GdaAttributesManager manages lists of named values (attibutes) for the benefit of
- others (objects or ressources for which only a pointer is known). It is used internally by &LIBGDA;
+ The #GdaAttributesManager manages lists of named values (attributes) for the benefit of
+ others (objects or resources for which only a pointer is known). It is used internally by &LIBGDA;
whenever an object or a simple structure may have several attributes.
</para>
<para>
diff --git a/doc/C/tmpl/gda-config.sgml b/doc/C/tmpl/gda-config.sgml
index 66fd6f5..bca3c88 100644
--- a/doc/C/tmpl/gda-config.sgml
+++ b/doc/C/tmpl/gda-config.sgml
@@ -22,7 +22,7 @@ g_object_new (GDA_TYPE_CONFIG, "user-file", "my_file", NULL);
</programlisting>
Please note that after that call, the caller has a reference to the newly created object, and should technically
call <link linkend="g-object-unref">g_object_unref()</link> when finished using it. It is safe to do this
- but also poinless since that object should not be destroyed (as no other will be created) as &LIBGDA; also
+ but also pointless since that object should not be destroyed (as no other will be created) as &LIBGDA; also
keeps a reference for itself.
</para>
<para>
diff --git a/doc/C/tmpl/gda-connection-event.sgml b/doc/C/tmpl/gda-connection-event.sgml
index f1e6e70..0732fbc 100644
--- a/doc/C/tmpl/gda-connection-event.sgml
+++ b/doc/C/tmpl/gda-connection-event.sgml
@@ -6,7 +6,7 @@ Any event which has occurred on a #GdaConnection
<!-- ##### SECTION Long_Description ##### -->
<para>
- Events occuring on a connection are each represented as a #GdaConnectionEvent object. Each #GdaConnection
+ Events occurring on a connection are each represented as a #GdaConnectionEvent object. Each #GdaConnection
is responsible for keeping a list of past events; that list can be consulted using the
gda_connection_get_events() function.
</para>
diff --git a/doc/C/tmpl/gda-connection.sgml b/doc/C/tmpl/gda-connection.sgml
index 9fa1e7f..98eb8fa 100644
--- a/doc/C/tmpl/gda-connection.sgml
+++ b/doc/C/tmpl/gda-connection.sgml
@@ -23,7 +23,7 @@ A connection to a database
<listitem><para>Request the statement execution using
<link linkend="gda-connection-async-statement-execute">gda_connection_async_statement_execute() which returns an
execution ID to be used to identify a specific request</link></para></listitem>
- <listitem><para>Do some usefull things (that is why async. statements' excution are for)</para></listitem>
+ <listitem><para>Do some useful things (that is why async. statements' excution are for)</para></listitem>
<listitem><para>Use one or more times
<link linkend="gda-connection-async-fetch-result">gda_connection_async_fetch_result()</link> to see
if the execution is finished, using the request ID</para></listitem>
@@ -37,7 +37,7 @@ A connection to a database
opened using those providers will only be accessible from the thread which created them (any other thread will
be blocked trying to access the connection, use the
<link linkend="gda-lockable-try-lock">gda_lockable_try_lock()</link> method to check it the connection
- is useable from a thread).
+ is usable from a thread).
</para>
<para>
If a connection really needs to be accessed by several threads at once, then it is possible to pass the
diff --git a/doc/C/tmpl/gda-data-handler.sgml b/doc/C/tmpl/gda-data-handler.sgml
index b4da311..5a0529f 100644
--- a/doc/C/tmpl/gda-data-handler.sgml
+++ b/doc/C/tmpl/gda-data-handler.sgml
@@ -18,7 +18,7 @@ Interface which provides data handling (conversions) capabilities
For each data type, a corresponding #GdaDataHandler object can be requested using the
<link linkend="gda-get-default-handler">gda_get_default_handler()</link> function. However, when working
with a specific database provider, it's better to use a #GdaDataHandler which may be specific to the
- database provider which will correctly handle each database specificities using
+ database provider which will correctly handle each database specifics using
<link linkend="gda-server-provider-get-data-handler-g-type">gda_server_provider_get_data_handler_g_type()</link> or
<link linkend="gda-server-provider-get-data-handler-dbms">gda_server_provider_get_data_handler_dbms()</link>.
</para>
diff --git a/doc/C/tmpl/gda-data-model-bdb.sgml b/doc/C/tmpl/gda-data-model-bdb.sgml
index b5b5860..18f41f1 100644
--- a/doc/C/tmpl/gda-data-model-bdb.sgml
+++ b/doc/C/tmpl/gda-data-model-bdb.sgml
@@ -29,16 +29,8 @@ virtual methods).
</para>
-
-<!-- ##### ARG GdaDataModelBdb:db-name ##### -->
-<para>
-
-</para>
-
-<!-- ##### ARG GdaDataModelBdb:filename ##### -->
-<para>
-
-</para>
+ object:
+ priv:
<!-- ##### STRUCT GdaDataModelBdbClass ##### -->
<para>
diff --git a/doc/C/tmpl/gda-data-model-dir.sgml b/doc/C/tmpl/gda-data-model-dir.sgml
index 1399854..3163e40 100644
--- a/doc/C/tmpl/gda-data-model-dir.sgml
+++ b/doc/C/tmpl/gda-data-model-dir.sgml
@@ -7,7 +7,7 @@ GdaDataModel to list files in filesystem
<!-- ##### SECTION Long_Description ##### -->
<para>
The #GdaDataModelDir object lists files on a filesystem which are located
-below a "basedir" directory, one file per row. The data model has the folllowing columns:
+below a "basedir" directory, one file per row. The data model has the following columns:
<itemizedlist>
<listitem><para>the "dir_name" column (G_TYPE_STRING): contains the dirname part of the file</para></listitem>
<listitem><para>the "file_name" column (G_TYPE_STRING): contains the file name part of the file</para></listitem>
diff --git a/doc/C/tmpl/gda-data-model-import.sgml b/doc/C/tmpl/gda-data-model-import.sgml
index c939807..b2c2fef 100644
--- a/doc/C/tmpl/gda-data-model-import.sgml
+++ b/doc/C/tmpl/gda-data-model-import.sgml
@@ -15,7 +15,7 @@ way it is also possible to import data from an already-build XML tree validated
</para>
<para>
The caller must decide, upon construction, if the new #GdaDataModelImport must support random access or simply
-a cursor based access. Random acces makes it easier to use the resulting data model but consumes more memory as
+a cursor based access. Random access makes it easier to use the resulting data model but consumes more memory as
all the data is copied in memory, and is thus not suitable for large data sets. Note that importing from an
already-build XML tree will always result in a random access data model.
</para>
diff --git a/doc/C/tmpl/gda-data-model.sgml b/doc/C/tmpl/gda-data-model.sgml
index 3b6bf5f..b2905f3 100644
--- a/doc/C/tmpl/gda-data-model.sgml
+++ b/doc/C/tmpl/gda-data-model.sgml
@@ -16,7 +16,7 @@ provided by the model. The actual operations a data model permits can be known u
gda_data_model_get_access_flags() method.
</para>
<para>
-Again, depending on the real implementation, data retreiving can be done either accessing direct random
+Again, depending on the real implementation, data retrieving can be done either accessing direct random
values located by their row and column, or using a cursor, or both. Use the gda_data_model_get_access_flags()
method to know how the data model can be accessed.
<itemizedlist>
diff --git a/doc/C/tmpl/gda-data-proxy.sgml b/doc/C/tmpl/gda-data-proxy.sgml
index 85bea91..d531d7e 100644
--- a/doc/C/tmpl/gda-data-proxy.sgml
+++ b/doc/C/tmpl/gda-data-proxy.sgml
@@ -44,10 +44,10 @@ Proxy to hold modifications for any #GdaDataModel, and provides the #GdaDataMode
</textobject>
</mediaobject>
- Note that unless explicitely mentionned, the columns are read-only.
+ Note that unless explicitly mentioned, the columns are read-only.
</para>
<para>
- The following figures illustrate row mappings bewteen the data proxy and the proxied data model in
+ The following figures illustrate row mappings between the data proxy and the proxied data model in
several situations (which can be combined, but are shown alone for simplicity):
<itemizedlist>
<listitem><para>situation where rows 1 and 5 have been marked as deleted from the data proxy, using
diff --git a/doc/C/tmpl/gda-data-select.sgml b/doc/C/tmpl/gda-data-select.sgml
index 7555e40..ea59224 100644
--- a/doc/C/tmpl/gda-data-select.sgml
+++ b/doc/C/tmpl/gda-data-select.sgml
@@ -14,7 +14,7 @@ Data models returned by the execution of a SELECT statement
<para>
The default behaviour however is to disallow modifications, and this section documents how to characterize
a <link linkend="GdaDataSelect">GdaDataSelect</link> to allow modifications. Once this is done, any modification
- done to the data model whill be propagated to the modified table in the database using INSERT, UPDATE or DELETE
+ done to the data model will be propagated to the modified table in the database using INSERT, UPDATE or DELETE
statements.
</para>
<para>
diff --git a/doc/C/tmpl/gda-meta-store.sgml b/doc/C/tmpl/gda-meta-store.sgml
index 0c102f0..687825f 100644
--- a/doc/C/tmpl/gda-meta-store.sgml
+++ b/doc/C/tmpl/gda-meta-store.sgml
@@ -14,7 +14,7 @@ Dictionary object
</para>
<para>
The new dictionary now relies on a database structure to store its data (see the
- <link linkend="information_schema">database schema</link> section for a detailled description). The actual database can be a
+ <link linkend="information_schema">database schema</link> section for a detailed description). The actual database can be a
single file (using an SQLite database), an entirely in memory database (also using an SQLite database), or
a more conventional backend such as a PostgreSQL database for a shared dictionary on a server.
</para>
diff --git a/doc/C/tmpl/gda-meta-struct.sgml b/doc/C/tmpl/gda-meta-struct.sgml
index 8afc1f4..f92fc6b 100644
--- a/doc/C/tmpl/gda-meta-struct.sgml
+++ b/doc/C/tmpl/gda-meta-struct.sgml
@@ -8,7 +8,7 @@ In memory representation of some database objects
<para>
The #GdaMetaStruct object reads data from a #GdaMetaStore object and
creates an easy to use in memory representation for some database objects. For example one can easily
- analyse the columns of a table (or its foreign keys) using a #GdaMetaStruct.
+ analyze the columns of a table (or its foreign keys) using a #GdaMetaStruct.
</para>
<para>
When created, the new #GdaMetaStruct object is empty (it does not have any information about any database object).
diff --git a/doc/C/tmpl/gda-pstmt.sgml b/doc/C/tmpl/gda-pstmt.sgml
index 3547239..fecb1d9 100644
--- a/doc/C/tmpl/gda-pstmt.sgml
+++ b/doc/C/tmpl/gda-pstmt.sgml
@@ -7,19 +7,19 @@ Prepared statement's base class
<!-- ##### SECTION Long_Description ##### -->
<para>
The #GdaPStmt represents the association between a #GdaStatement statement and a <emphasis>prepared statement</emphasis>
- which is database dependant and is an in-memory representation of a statement. Using prepared statement has the
+ which is database dependent and is an in-memory representation of a statement. Using prepared statement has the
following advantages:
<itemizedlist>
<listitem><para>the parsing of the SQL has to be done only once, which improves performances if the statement
has to be executed more than once</para></listitem>
- <listitem><para>if a statement has been prepared, then it means it is syntaxically correct and has been
+ <listitem><para>if a statement has been prepared, then it means it is syntactically correct and has been
<emphasis>understood</emphasis> by the database's API</para></listitem>
<listitem><para>it is possible to use variables in prepared statement which eliminates the risk
of SQL code injection</para></listitem>
</itemizedlist>
</para>
<para>
- The #GdaPStmt is not intended to be instanciated, but subclassed by database provider's implementation.
+ The #GdaPStmt is not intended to be instantiated, but subclassed by database provider's implementation.
Once created, the database provider's implementation can decide to associate (for future lookup) to
a #GdaStatement object in a connection using
<link linkend="gda-connection-add-prepared-statement">gda_connection_add_prepared_statement()</link>.
diff --git a/doc/C/tmpl/gda-report-engine.sgml b/doc/C/tmpl/gda-report-engine.sgml
index baf13ee..9c18887 100644
--- a/doc/C/tmpl/gda-report-engine.sgml
+++ b/doc/C/tmpl/gda-report-engine.sgml
@@ -70,7 +70,7 @@ Low level report generator based on XML
<query_name>|@<column_name> (such as "customers|@@name" for the "name" column)
and <query_name>|#<column_number>,
(such as "customers|##0" for the first column).
- Those parameters can be used in any child node (recusively),
+ Those parameters can be used in any child node (recursively),
and have their value updated for each row of the data model.
For more information about the parameter's syntax,
see the <link linkend="SQL_queries">GDA SQL query syntax</link>.
diff --git a/doc/C/tmpl/gda-server-operation-sequences.sgml b/doc/C/tmpl/gda-server-operation-sequences.sgml
index 186cc23..6b0d546 100644
--- a/doc/C/tmpl/gda-server-operation-sequences.sgml
+++ b/doc/C/tmpl/gda-server-operation-sequences.sgml
@@ -9,7 +9,7 @@ Manipulating sequences
The #GdaServerOperation object can contain sequences of templates. For example when creating a table,
one can specify several foreign keys where for each foreign key, one must define the column(s) on which the
foreign key applies, the referenced table and the corresponding columns of the referenced table (plus some
- additionnal information). In this case the foreign keys are defined as a sequence of templates (the foreign key
+ additional information). In this case the foreign keys are defined as a sequence of templates (the foreign key
definition): there can be zero or more foreign keys.
</para>
diff --git a/doc/C/tmpl/gda-server-operation.sgml b/doc/C/tmpl/gda-server-operation.sgml
index fb958f7..03d1ae2 100644
--- a/doc/C/tmpl/gda-server-operation.sgml
+++ b/doc/C/tmpl/gda-server-operation.sgml
@@ -7,7 +7,7 @@ Handles any DDL query in an abstract way
<!-- ##### SECTION Long_Description ##### -->
<para>
This object is basically just a data store: it can store named values, the values being
- organized hirarchically by their name which are similar to a Unix file path. For example a value can be read from its path
+ organized hierarchically by their name which are similar to a Unix file path. For example a value can be read from its path
using the gda_server_operation_get_value_at() method, or set using the gda_server_operation_set_value_at() method.
</para>
<para>
diff --git a/doc/C/tmpl/gda-server-provider.sgml b/doc/C/tmpl/gda-server-provider.sgml
index 2a3d711..c797b51 100644
--- a/doc/C/tmpl/gda-server-provider.sgml
+++ b/doc/C/tmpl/gda-server-provider.sgml
@@ -7,7 +7,7 @@ Base class for all the DBMS providers
<!-- ##### SECTION Long_Description ##### -->
<para>
The #GdaServerProvider class is a virtual class which all the DBMS providers
- must inherit, and implement its virtual mathods.
+ must inherit, and implement its virtual methods.
</para>
<para>
See the <link linkend="libgda-provider-class">Virtual methods for providers</link> section for more information
diff --git a/doc/C/tmpl/gda-set.sgml b/doc/C/tmpl/gda-set.sgml
index 294389a..8e34d45 100644
--- a/doc/C/tmpl/gda-set.sgml
+++ b/doc/C/tmpl/gda-set.sgml
@@ -274,7 +274,7 @@ Container for several values
<!-- ##### STRUCT GdaSetGroup ##### -->
<para>
There is one #GdaSetGroup structure
- for each _independant_ #GdaHolder (those which have the same restricting data model
+ for each _independent_ #GdaHolder (those which have the same restricting data model
all appear in the same #GdaSetGroup structure).
</para>
diff --git a/doc/C/tmpl/gda-sql-parser.sgml b/doc/C/tmpl/gda-sql-parser.sgml
index 16a4dc3..0b916bf 100644
--- a/doc/C/tmpl/gda-sql-parser.sgml
+++ b/doc/C/tmpl/gda-sql-parser.sgml
@@ -21,7 +21,7 @@ SQL parser
for the next statement in the string to parse (and create a GDA_SQL_STATEMENT_UNKNOWN statement).
</para>
<para>
-The #GdaSqlParser object parses and analyses SQL statements and reports the following statement types:
+The #GdaSqlParser object parses and analyzes SQL statements and reports the following statement types:
<itemizedlist>
<listitem><para>SELECT (and COMPOUND select),
INSERT, UPDATE and DELETE SQL statements should be completely parsed.
@@ -31,7 +31,7 @@ The #GdaSqlParser object parses and analyses SQL statements and reports the foll
extract some information (that structure is not enough per-se to re-create the complete SQL statement).
</para></listitem>
<listitem><para>Any other type of SQL statement (CREATE TABLE, ...) creates a #GdaStatement of type
- GDA_SQL_STATEMENT_UNKNOW, and it only able to locate place holders (variables) and end of statement
+ GDA_SQL_STATEMENT_UNKNOWN, and it only able to locate place holders (variables) and end of statement
marks.</para></listitem>
</itemizedlist>
</para>
@@ -42,7 +42,7 @@ NOTE: Any SQL of a type which should be parsed which but which creates a #GdaSta
<para>
The #GdaSqlParser object recognizes place holders (variables), which can later be queried and valued using
-gda_statement_get_parameters(). The folllowing syntax are recognized (other syntaxes might be
+gda_statement_get_parameters(). The following syntax are recognized (other syntaxes might be
recognized for specific database providers if the #GdaSqlParser is created using gda_server_provider_create_parser()
but for portability reasons it's better to avoid them):
<itemizedlist>
@@ -107,11 +107,6 @@ ALTER GROUP mygroup ADD USER ##name::gchararray;
Internal usage only.
</para>
-<!-- ##### ARG GdaSqlParser:debug ##### -->
-<para>
-Forces the parser to display somme debug information.
-</para>
-
<!-- ##### ARG GdaSqlParser:line-error ##### -->
<para>
Internal usage only.
@@ -133,7 +128,7 @@ Modifies the behaviour of the tokenizer, reserved for #GdaServerProvider impleme
</para>
@GDA_SQL_PARSER_MODE_PARSE: Parse mode, the parser tries to parse and build a structure representing the SQL statement
- GDA_SQL_PARSER_MODE_DELIMIT: Delimit mode, the parser only tries to identify variables, will always return a statement of type GDA_SQL_STATEMENT_UNKNOW.
+ GDA_SQL_PARSER_MODE_DELIMIT: Delimit mode, the parser only tries to identify variables, will always return a statement of type GDA_SQL_STATEMENT_UNKNOWN.
<!-- ##### FUNCTION gda_sql_parser_new ##### -->
<para>
diff --git a/doc/C/tmpl/gda-sql-statement.sgml b/doc/C/tmpl/gda-sql-statement.sgml
index dfcb147..aff4d7b 100644
--- a/doc/C/tmpl/gda-sql-statement.sgml
+++ b/doc/C/tmpl/gda-sql-statement.sgml
@@ -598,7 +598,7 @@ Specifies the type of functions passed to gda_sql_any_part_foreach().
<!-- ##### STRUCT GdaSqlStatementCompound ##### -->
<para>
The statement is a compound selection statement: multiple SELECT or compound statements composed together with UNION, EXCEPT or
- INSERSECT operations. Any kind of compound statement can be represented using this structure
+ INTERSECT operations. Any kind of compound statement can be represented using this structure
(if this is not the case
then report a bug).
<mediaobject>
diff --git a/doc/C/tmpl/gda-transaction-status.sgml b/doc/C/tmpl/gda-transaction-status.sgml
index 525e2f0..d5feea2 100644
--- a/doc/C/tmpl/gda-transaction-status.sgml
+++ b/doc/C/tmpl/gda-transaction-status.sgml
@@ -2,7 +2,7 @@
GdaTransactionStatus
<!-- ##### SECTION Short_Description ##### -->
-Keeps track of the transactional status of a connection
+Keeps track of the transaction status of a connection
<!-- ##### SECTION Long_Description ##### -->
<para>
diff --git a/doc/C/tmpl/gda-tree-manager.sgml b/doc/C/tmpl/gda-tree-manager.sgml
index cf1900b..9cc1efc 100644
--- a/doc/C/tmpl/gda-tree-manager.sgml
+++ b/doc/C/tmpl/gda-tree-manager.sgml
@@ -17,7 +17,7 @@ Base class for all the tree managers
object's property, or, if not specified that way, are fetched as attributes.
</para>
<para>
- The #GdaTreeManager itself is an abstract type (which can't be instanciated). Use an existing sub class or subclass
+ The #GdaTreeManager itself is an abstract type (which can't be instantiated). Use an existing sub class or subclass
it yourself.
</para>
diff --git a/doc/C/tmpl/gda-tree-mgr-label.sgml b/doc/C/tmpl/gda-tree-mgr-label.sgml
index 615e233..6839670 100644
--- a/doc/C/tmpl/gda-tree-mgr-label.sgml
+++ b/doc/C/tmpl/gda-tree-mgr-label.sgml
@@ -7,7 +7,7 @@ a tree manager which creates a single node
<!-- ##### SECTION Long_Description ##### -->
<para>
The #GdaTreeMgrLabel is a #GdaTreeManager object which creates a single node. This tree manager
- is usefull to create "sections" in a #GdaTree hierarchy.
+ is useful to create "sections" in a #GdaTree hierarchy.
</para>
<!-- ##### SECTION See_Also ##### -->
diff --git a/doc/C/tmpl/gda-value.sgml b/doc/C/tmpl/gda-value.sgml
index 01232d4..98ad6b1 100644
--- a/doc/C/tmpl/gda-value.sgml
+++ b/doc/C/tmpl/gda-value.sgml
@@ -13,7 +13,7 @@ Assorted functions for dealing with #GValue values.
Libgda makes a distinction between binary and blob types
<itemizedlist>
<listitem><para>binary data can be inserted into an SQL statement using a
- (DBMS dependant) syntax, such as "X'ABCD'" syntax for SQLite or the binary strings syntax for PostgreSQL. Binary data
+ (DBMS dependent) syntax, such as "X'ABCD'" syntax for SQLite or the binary strings syntax for PostgreSQL. Binary data
is manipulated using a #GdaBinary structure (which is basically a bytes buffer and a length attribute).
</para></listitem>
<listitem><para>blob data are a special feature that some DBMS have which requires some non SQL code to manipulate them.
diff --git a/doc/C/tmpl/gda-vconnection-hub.sgml b/doc/C/tmpl/gda-vconnection-hub.sgml
index ba3a967..00833a9 100644
--- a/doc/C/tmpl/gda-vconnection-hub.sgml
+++ b/doc/C/tmpl/gda-vconnection-hub.sgml
@@ -16,7 +16,7 @@ when adding a connection using gda_vconnection_hub_add()).
<para>
For example if a connection A has two tables 'table_1' and 'table_2', then after gda_vconnection_hub_add() has been called
with A as connection argument and with a "c1" namespace, then in the corresponding #GdaVconnectionHub connection, table
-'table_1' must be refered to as 'c1.table_1' and 'table_2' must be refered to as 'c1.table_2'.
+'table_1' must be referred to as 'c1.table_1' and 'table_2' must be referred to as 'c1.table_2'.
</para>
&libgda-virtual-notice;
diff --git a/doc/C/tmpl/gda-xa-transaction.sgml b/doc/C/tmpl/gda-xa-transaction.sgml
index b3c5f4c..2f428be 100644
--- a/doc/C/tmpl/gda-xa-transaction.sgml
+++ b/doc/C/tmpl/gda-xa-transaction.sgml
@@ -60,7 +60,7 @@ Distributed transaction manager
<!-- ##### STRUCT GdaXaTransactionId ##### -->
<para>
Distributed transaction identification, composed of a global format identifier, a global transaction identifier, and a
-branch qualifier. For any connection participating in the global transactio, the format and global transaction identifier
+branch qualifier. For any connection participating in the global transaction, the format and global transaction identifier
should be the same, and the branch qualifier should vary between the connections.
</para>
diff --git a/doc/C/tmpl/provider-support-sql.sgml b/doc/C/tmpl/provider-support-sql.sgml
index 26919be..5b567c7 100644
--- a/doc/C/tmpl/provider-support-sql.sgml
+++ b/doc/C/tmpl/provider-support-sql.sgml
@@ -74,7 +74,7 @@ Adapting the SQL to the database's own SQL dialect
</para>
@value: the #GValue to render
- context: the rendering contect
+ context: the rendering context
@error: a place to store errors, or %NULL
@Returns: a new string, or %NULL if an error occurred
@@ -86,7 +86,7 @@ Adapting the SQL to the database's own SQL dialect
@pspec: #GdaSqlParamSpec to render
@expr: #GdaSqlExpr which may hold the default value for the parameter, or %NULL
- context: the rendering contect
+ context: the rendering context
@is_default: pointer to a #gboolean which is set to TRUE if value should be considered as a default value
@is_null: pointer to a #gboolean which is set to TRUE if value should be considered as NULL
@error: a place to store errors, or %NULL
@@ -99,7 +99,7 @@ Adapting the SQL to the database's own SQL dialect
</para>
@expr: #GdaSqlExpr to render
- context: the rendering contect
+ context: the rendering context
@is_default: pointer to a #gboolean which is set to TRUE if value should be considered as a default value
@is_null: pointer to a #gboolean which is set to TRUE if value should be considered as NULL
@error: a place to store errors, or %NULL
@@ -112,7 +112,7 @@ Adapting the SQL to the database's own SQL dialect
</para>
@node: a #GdaSqlAnyPart pointer, to be cast to the correct type depending on which part the function has to render
- context: the rendering contect
+ context: the rendering context
@error: a place to store errors, or %NULL
@Returns: a new string, or %NULL if an error occurred
diff --git a/doc/C/tmpl/provider-support.sgml b/doc/C/tmpl/provider-support.sgml
index 67efd17..147ac38 100644
--- a/doc/C/tmpl/provider-support.sgml
+++ b/doc/C/tmpl/provider-support.sgml
@@ -6,7 +6,7 @@ Methods dedicated to implementing providers
<!-- ##### SECTION Long_Description ##### -->
<para>
- The methods mentionned in this section are reserved for database providers implementatins and should
+ The methods mentioned in this section are reserved for database providers implementations and should
not bu used by developers outside that scope.
</para>
diff --git a/doc/C/virtual.xml b/doc/C/virtual.xml
index a3d0dfd..99ea3df 100644
--- a/doc/C/virtual.xml
+++ b/doc/C/virtual.xml
@@ -27,7 +27,7 @@ cnc = gda_virtual_connection_open (provider, NULL);
</programlisting>
</para>
<para>
- Some examples of virtual connections usage can be found in the source distribtion of Libgda in:
+ Some examples of virtual connections usage can be found in the source distribution of Libgda in:
<itemizedlist>
<listitem><para><filename class="directory">samples/Virtual</filename></para></listitem>
<listitem><para><filename class="directory">samples/DirDataModel</filename></para></listitem>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
