view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    should also read the section on ExtUtils::MakeMaker in the 2nd Edition
    of 'Programming Perl'.

    You should never need to make any changes to the generated Makefile,
    nor to Makefile.PL.  If you do *please* let me know so that I can try
    to make it automatic in a later release.

  *------------------------    NOT YET!  --------------------------------
  |
  | The "make test" facility documented here is currently unavailable
  | with the DBD::Sqlflex release.  It should be fully implemented soon.
  | Sorry for any inconvenience.
  |
  *----------------------------------------------------------------------
  | Then run:
  |
  |     make test
  |
  | Note that testing DBD::Sqlflex does create some tables and databases.
  | The database is normally called 'dbd_ix_db', and the table names start
  | with 'dbd_ix_'.  Some of the tables are permanent; most are temporary.
  | The tests are designed to work whether the tables and database are
  | present when the tests start or not; that means they get dropped.  Do
  | not run the tests if you have precious tables or databases that begin
  | 'dbd_ix_'!
  |
  | It is a good idea to run:
  |
  |     make test TEST_VERBOSE=1
  |
  | You should inspect the results as not every test compares the actual
  | data returned with the data that should be returned (though many of
  | them do check the data which is returned).
  |
  | Additionally, for a really thorough scrutiny of DBD::Sqlflex, you need
  | to test with at least 3 different databases: one created MODE ANSI, one
  | created with a transaction log but not MODE ANSI, and one created
  | without any transaction logs at all.
  |
  |     DBD_SQLFLEX_DATABASE=mode_ansi make test
  |     DBD_SQLFLEX_DATABASE=logged    make test
  |     DBD_SQLFLEX_DATABASE=unlogged  make test
  |
  *----------------------------------------------------------------------

    Once you are satisfied that DBD::Sqlflex is working correctly, you
    should install it:

        make install

    If you ever need to remove it, possibly as a preamble to installing a
    new version, you should use the old version's makefile and run:

        make uninstall

    You can then install using the new version's makefile.  It is important
    to use the correct (old or new) makefiles because the installed files
    may be different, and if some file is made obsolete by the new version
    (is not used by the new version), its makefile will not uninstall the
    obsolete file; over time and multiple versions, this could, eventually,
    lead to 'coronary thrombosis' on your disk drive -- or disk full.

KNOWN PROBLEMS:

    None at this time.

IF YOU HAVE PROBLEMS BUILDING DBD::SQLFLEX

Firstly, check the Frequently Asked Questions, Known Bugs and any other
pertinent documents at:

    http://www.arcana.co.uk/technologia/DBI

If this does *not* resolve your problem, please post the details of your
problem to dbi-users@fugue.com and CC them to me at help@infoflex.com

There are 4 types of failures which you might encounter:
    A.  A configuration failure (perl Makefile.PL does not work)
    B.  A build failure (the Makefile was generated but there were problems
        during the build proper so that no test worked at all)
    C.  A general test failure (although the build appeared OK, every
        single test fails, or almost all of them fail).
    D.  A selective test failure (the build appeared OK and most of the
        tests pass, but a few (say 1 to 5) of them fail).
Please classify your problem and follow the relevant steps below.

Please include:

1. A log of a complete build:

    # Before doing anything, please either re-extract the source from the
    # compressed tar file you retrieved from CPAN into an empty directory
    # or make sure that the build area is really clean:
    [ -f Makefile ] && make realclean
    rm -f esql esqlvrsn.h

    # Send this output for all failure types (A, B, C, D)
    perl Makefile.PL

    # Send this output for failure types B, C, D.
    make

    # Send this output for failure types C, D
    # If the output is more than about 30 lines, then just send the first
    # 30 lines or so of the output -- anything more is unlikely to give any
    # extra information.
    make test

    # Send this output for failure types C, D
    # Then, taking the first test which fails (typically basic00.t) send
    # the output from:
    test.one t/basic00.t

    # Send this output for failure type D
    # If the failing tests are failing in distinctly different ways
    # (different error messages, or one is a core dump, or ...) then send
    # the test output for each of the different outputs, but do not send
    # more than 5 sets of test results unless requested to do so.
    test.one t/dbase.t

    If you use a Bourne or Korn Shell (or any work-alikes), you can also