bk commit - mysqldoc@docsrva tree (stefan:1.2824)

[stefan]

Below is the list of changes that have just been committed into a local
mysqldoc repository of stefan. When stefan does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.2824 05/06/19 22:49:45 stefan@stripped +3 -0
  introduction.xml:
    Remove opinion about Oracle
    Sync with refman

  refman/introduction.xml
    1.2 05/06/19 22:49:30 stefan@stripped +1 -10
    Remove opinion about Oracle

  refman-4.1/introduction.xml
    1.2 05/06/19 22:49:18 stefan@stripped +1 -10
    Sync with refman

  refman-5.0/introduction.xml
    1.2 05/06/19 22:49:02 stefan@stripped +1 -10
    Sync with refman

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	stefan
# Host:	apollon.site
# Root:	/home/stefan/bk/mysqldoc

--- 1.1/refman-4.1/introduction.xml	2005-06-16 21:35:23 +02:00
+++ 1.2/refman-4.1/introduction.xml	2005-06-19 22:49:18 +02:00
@@ -3329,7 +3329,7 @@
    </para>
 
    <para>
-    ODBC levels 0−3.51.
+    ODBC levels 0-3.51.
    </para>
 
   </section>
@@ -4113,15 +4113,6 @@
      </para></listitem>
 
      <listitem><para>
-      Even a transactional system can lose data if the server goes down.
-      The difference between different systems lies in just how small
-      the time-lag is where they could lose data. No system is 100%
-      secure, only ``secure enough.'' Even Oracle, reputed to be the
-      safest of transactional database systems, is reported to sometimes
-      lose data in such situations.
-     </para>
-
-     <para>
       To be safe with MySQL Server, whether or not using transactional
       tables, you only need to have backups and have binary logging
       turned on. With this you can recover from any situation that you

--- 1.1/refman-5.0/introduction.xml	2005-06-16 21:46:21 +02:00
+++ 1.2/refman-5.0/introduction.xml	2005-06-19 22:49:02 +02:00
@@ -3329,7 +3329,7 @@
    </para>
 
    <para>
-    ODBC levels 0−3.51.
+    ODBC levels 0-3.51.
    </para>
 
   </section>
@@ -4113,15 +4113,6 @@
      </para></listitem>
 
      <listitem><para>
-      Even a transactional system can lose data if the server goes down.
-      The difference between different systems lies in just how small
-      the time-lag is where they could lose data. No system is 100%
-      secure, only ``secure enough.'' Even Oracle, reputed to be the
-      safest of transactional database systems, is reported to sometimes
-      lose data in such situations.
-     </para>
-
-     <para>
       To be safe with MySQL Server, whether or not using transactional
       tables, you only need to have backups and have binary logging
       turned on. With this you can recover from any situation that you

--- 1.1/refman/introduction.xml	2005-06-16 01:46:57 +02:00
+++ 1.2/refman/introduction.xml	2005-06-19 22:49:30 +02:00
@@ -3329,7 +3329,7 @@
    </para>
 
    <para>
-    ODBC levels 0−3.51.
+    ODBC levels 0-3.51.
    </para>
 
   </section>
@@ -4113,15 +4113,6 @@
      </para></listitem>
 
      <listitem><para>
-      Even a transactional system can lose data if the server goes down.
-      The difference between different systems lies in just how small
-      the time-lag is where they could lose data. No system is 100%
-      secure, only ``secure enough.'' Even Oracle, reputed to be the
-      safest of transactional database systems, is reported to sometimes
-      lose data in such situations.
-     </para>
-
-     <para>
       To be safe with MySQL Server, whether or not using transactional
       tables, you only need to have backups and have binary logging
       turned on. With this you can recover from any situation that you