Conectar con Access / Connect with Access.
Código fuente / Source code :

$pathDB = str_replace("/", "\\", $_SERVER["DOCUMENT_ROOT"]) . "\\directory1\\directory2\\bdd.mdb";

if(!file_exists($pathDB))
{
echo "!!! Base de datos no encontrada ".$pathDB;
exit;
}

$conexion = odbc_connect("DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=".$pathDB, "ADODB.Connection", "", "SQL_CUR_USE_ODBC");
$sql="select * from tabla where 1";
$resultado=odbc_exec($conexion,$sql);
if($resultado)
{
	while($fila=odbc_fetch_array($resultado))
	{
	echo $fila['campo1']."<br />";
	echo $fila['campo2']."<br />";
	}
odbc_close_all();
}

This is something kinda experimental I'm working on. Testing is cool, but I hate that it's separate from my code. Perhaps that's stupidity on my part, but I wanted to see if there's a way to bring the lowest level of testing directly into the class..

module InPlaceTesting
  def self.included(klass)
    old_method_added = klass.method(:method_added)
    new_method_added = lambda do |m|
      @@current_method = m
      old_method_added.call m
    end
    
    # Next line inspired by http://utils.ning.com/ruby/dbc.rb by Brian McCallister and Martin Traverso
    (class << klass; self; end).send :define_method, :method_added, new_method_added
    
    class << klass
      def given(*args)
        self.new.send @@current_method, *args
      end
      def method_should(message, params)
        unless params[:return] == params[:when]
          puts "\"#{@@current_method}\" fails to #{message} (returns #{params[:when]} instead of #{params[:return]})"
        end
      end
    end
    
  end
  
end

class DumbClass
  include InPlaceTesting

  def add(x,y) 
    x + y
  end
  method_should "add 5 and 4", :return => 9, :when => given(5, 4)

  def subtract(x,y) 
    x - y
  end 
  method_should "subtract 5 from 14", :return => 9, :when => given(14,5)
  
  def increment(x)
    x + 1
  end
  method_should "increment 12", :return => 13, :when => given(12)
end

From http://www.reevoo.com/blogs/bengriffiths/2005/06/24/a-test-by-any-other-name/:

We find that the pattern ‘test_should_***_on_***’ a useful way of naming tests – it’s an idea stolen from JBehave . If this test were to fail, I’m reminded that I should (!) ask myself the question ‘should the class I’m testing do this?’ before I go on a bug-hunt. The other advantage is that I can use my test classes to generate some simple documentation for my classes. Here’s a rake target that can do just that:

desc "Generate agiledox-like documentation for tests"
task :agiledox do
  tests = FileList['test/**/*_test.rb']
  tests.each do |file|
    m = %r".*/([^/].*)_test.rb".match(file)
    puts m[1]+" should:\n"
    test_definitions = File::readlines(file).select {|line| line =~ /.*def test.*/}
    test_definitions.each do |definition|
      m = %r"test_(should_)?(.*)".match(definition)
      puts " - "+m[2].gsub(/_/," ")
    end
  puts "\n"
 end
end

An example from our codebase, typing rake agiledox generates:

security_controller should:
- redirect to page stored in session on successful login
- store user object in session on successful login
- redirect to page stored in session after signup
- store user object in session after signup
- reject signup when passwords do not match
- reject signup when login too short
- report both errors if passwords dont match and username too short
- not store user in session if password not correct on signup
- remain on login page if password not correct on signup
- remove user from session on log out