Re: [sqlite] Version 3.3.0 (alpha)

[Roger Binns]

 ... But new databases created by
 version 3.3.0 will not be readable by older versions
 of SQLite.  If this is a problem for your application,
 compile SQLite using

-DSQLITE_DEFAULT_FILE_FORMAT=1

 and then version 3.3.0 will create new databases in
 the legacy format understood by all prior versions of
 SQLite.  DESC indices only work in the new format.


Is there any chance that could also be set by a pragma?
The problem is when supplying binary versions of SQLite,
it isn't immediately obvious which format to make the
default and developers can't set it even if they do know
without recompiling themselves.  I'd imagine the packagers
for various Linux/BSD distributions will have the same
problem.

Roger

Re: [sqlite] Two problems

[Dan Kennedy]

> - insert the value "0E9" (and other variables that would look like numbers
>   if they were in numeric fields) into a varchar(10) field, and it gets
>   converted to the numeric equivalent.

I think it might the perl wrapper doing the conversion. SQLite shouldn't
do this.

SQLite version 3.3.0
sqlite> create table a(b varchar(10));
sqlite> insert into a values('0E9');
sqlite> select * from a;
0E9
sqlite> select typeof(b) from a;
text
sqlite> insert into a values(0E9);
sqlite> select typeof(b) from a;
text
text
sqlite> select b from a;
0E9
0E9
 
> - The second problem appears to be a problem with self-locking.  I'm
>   inserting a "mapping" into a table.  I have a query active to find ids
>   that require mapping, and then I try to find the current lowest
>   unused "mapping" value, and insert it.

Right. You can't modify a table that is currently being scanned by
a SELECT query. One way around this is to make a copy of the table
in a TEMP table for the duration of the operation.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[sqlite] Two problems

[Paul Tomblin]

I'm just testing out my http://navaid.com/ applications with SQLite.  In
the past, my scripts have worked with MySQL and PostgreSQL with minimal
changes, but I'm getting two problems with SQLite in perl DBD::SQLite:

- insert the value "0E9" (and other variables that would look like numbers
  if they were in numeric fields) into a varchar(10) field, and it gets
  converted to the numeric equivalent.  The identical syntax worked fine
  with MySQL and PostgresSQL.  The schema looks like:
sqlite> .schema waypoint
CREATE TABLE waypoint (
  id varchar(10) default NULL,
  datasource_key varchar(20) default NULL,
  type varchar(30) default NULL,
  name varchar(100) default NULL,
  address varchar(120) default NULL,
  state char(3) default NULL,
  country char(2) default NULL,
  latitude double default NULL,
  longitude double default NULL,
  declination double default NULL,
  datasource smallint(6) default NULL,
  elevation double default NULL,
  main_frequency varchar(9) default NULL,
  ispublic tinyint(1) default NULL,
  chart_map smallint(6) default NULL,
  tpa smallint(6) default NULL
);
CREATE INDEX waypoint_datasource on waypoint(datasource);
CREATE INDEX waypoint_id on waypoint(id);
CREATE INDEX waypoint_type on waypoint(type);
sqlite> 
 and is inserted with
$wptInsertStmt = $conn->prepare(qq{
INSERT INTO waypoint
(id, datasource_key, type, name, address,
state, country,
latitude, longitude, declination,
elevation, main_frequency, datasource,
ispublic, chart_map)
VALUES  (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?, ?)});
$wptInsertStmt->execute($id, $datasource_key, $type,
$name, $address, $state, $country,
$latitude, $longitude, $declination, $elevation,
$main_frequency, $datasource, $isPublic, $chart_map)
or die $wptInsertStmt->errstr;
print "Inserted $type: $id\n";

- The second problem appears to be a problem with self-locking.  I'm
  inserting a "mapping" into a table.  I have a query active to find ids
  that require mapping, and then I try to find the current lowest
  unused "mapping" value, and insert it.  But when I do, the open query
  seems to have locked the database against itself, and I get an error:
DBD::SQLite::st execute failed: database table is locked(1) at dbdimp.c
line 401 at /config_backup/navaid.com//perl/DBLoad_lite.pm line 547.
  The code in question:
my $selectStmt = $conn->prepare(
"SELECT distinct(a.id) " .
"FROM   waypoint a " .
"LEFT JOIN  id_mapping b " .
"ON a.id = b.id " .
"WHERE  b.id is null");
my $insertStmt = $conn->prepare(
"INSERT " .
"INTO   id_mapping(id, pdb_id) " .
"VALUES (?,?)");
$selectStmt->execute() or die $selectStmt->errstr;

while (my @row = $selectStmt->fetchrow_array)
{
my ($id) = @row;
print "new ID: $id\n";

$maxNumber = nextId($maxNumber);
print "inserting $id,  $maxNumber\n";
$insertStmt->execute($id, $maxNumber++);  #<-- this is line 547
}

  nextID does the following:
while (1)
{
$isTaken->execute($maxNumber);
if (@row = $isTaken->fetchrow_array)
{
print "$maxNumber is already taken\n";
$maxNumber++;
}
else
{
last;
}
}
return $maxNumber;
  Any ideas?

-- 
Paul Tomblin <[EMAIL PROTECTED]> http://xcski.com/blogs/pt/
If the automobile had followed the same development as the computer a
Rolls Royce would today cost $100, get a million miles per gallon and
explode once a year killing everybody inside. - Robert Cringley (InfoWorld)

Re: [sqlite] PRAGMA table_info oddness

[Kurt Welgehausen]

There's no string type in SQL. Go to

and read section 2.1.

Regards

[sqlite] PRAGMA table_info oddness

[Mike Ashmore]

Hi folks,
I'm trying to create a composite view from multiple database files,  
with an extra field for the origin of a particular record. A sample  
scenario:


There's a table, "foo," which exists in two database files, 'a.db3'  
and 'b.db3'. Let's define it as:

CREATE TABLE foo (f1 integer, f2 string);

Now, we open up a :memory: database and do the following:
ATTACH 'a.db3' as a;
ATTACH 'b.db3' as b;
CREATE TEMP VIEW foo AS
SELECT *, 'a' AS origin FROM a.foo
UNION
SELECT *, 'b' AS origin FROM b.foo;

PRAGMA table_info(foo);
gives:
0|f1|numeric|0||0
1|f2|string|0||0
2|origin|numeric|0||0

The problem is that I'd like origin to be reported as type string. Is  
there something in SQL syntax that I've missed which allows me to  
specify this?


I'm trying to integrate the composite view into a Ruby on Rails  
application, and RoR seems to rely on the type reported by the  
table_info pragma to determine what format to use when updating or  
inserting records [1][2].


I've determined this happens with SQLite 3.2.8 and below; I have not  
yet tested against the 3.3.x series.


Thanks in advance for any help you can provide with this,
-Mike Ashmore

[1] Of course one can't insert, update, or delete on a view directly;  
I have a set of INSTEAD OF triggers which ask a separate process to  
modify the tables in their original database files.


[2] If there are any RoR users here who know how to override this  
behavior cleanly (manually specifying column types), I'd also love to  
know about that mechanism.

[sqlite] Writing/reading blobs

[Robert Bielik]

Hi all,

I'm using SQLite3 via the SQLite ODBC wrapper. Amongst other things I need 
to store large blobs. When using ODBC this means several calls to 
SQLPutData/SQLGetData. I've read the docs and it seems that SQLite doesn't 
support this. Is this in planning, and/or can someone well versed in the 
code of SQLite say if this is doable?


Regards,
/Rob

Re: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

[John Stanton]

Fred makes a good point.  A well conceived software solution is a good 
investment and a slipshod, makeshift solution not an investment but an 
ongoing liability.  We have some software which was carefully thought 
through initially and has been in constant national use for close to 
twenty years again on generation after generation of hardware, simply 
because the problem did not change.  Surely one's clients deserve to 
have their money spent prudently in the spirit of "If you don't have 
time to do it right you don't have time to do it twice".


I would expect that some of the Sqlite applications being developed 
today will have an inherent simplicity and direct function such that 
they will also be functioning in decades hence despite fashion changes 
and hardware advances.   Sqlite follows Einstein's view "Make it as 
simple as possible but no simpler".  JS


Fred Williams wrote:

You points are understood.  But I've always attempted to use a hammer
for a nail and a screwdriver for a screw.  This extra effort always
produces a much cleaner and professional result.

Good clients know that response time is money and resources they spend
every day and at every seat.  Proper software development is a high cost
one time event.  I have had occasion to see code I have written running
five plus years after implementation.  In that time migrated across
three platforms.

Fred



-Original Message-
From: Steve O'Hara [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 22, 2006 4:06 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java


You're right to a certain extent, but the point I was trying
to address
was the ideal of being able to use an SQLite database from a
variety of
toolsets and environments natively.  If you've ever written JNI you'll
know why this is a pain and a Java only implementation would be sweet.

Also, not all SQL engines work the same way and I'm certain HSQLD is
slower than SQLite architecturally, not because it's implemented in
Java.  After all, there is a non-free variant of HSQLDB
(HyperXtremSQL)
written in Java by the same author that is 50% faster - he didn't get
that by tweaking the code, more like re-architecting the storage.

The language is just a tool, a way of describing a solution to a
machine.  The judgement of performance etc of a language is a little
specious because it implies a generalisation of how the language is
implemented on a particular platform.  I've learned to like
Java because
I've got a beautiful development environment (intelliJ IDEA) and in my
professional life, speed/quality of development is more important than
response times.  My clients would prefer to spend more money
on hardware
than on consultancy - who can blame them.

Steve

-Original Message-
From:
[EMAIL PROTECTED]
[mailto:sqlite-users-return-10034-sohara=pivotal-solutions.co.
[EMAIL PROTECTED]
org] On Behalf Of Fred Williams
Sent: 21 January 2006 15:52
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

I think if you will closely read you own analysis of your efforts you
will realize that all of the "down side" issues you have enumerated
relate directly to the implementation language and not the database or
its structure.  In Java there is no such thing as AnythingLite, IMHO.
Java, like so many other languages has grown well beyond its initial
intent, small, simple applets imbedded on a web page.

With all of our advances in programming we still have not evolved that
"perfect" language, and most likely never will.  I spite of what those
"C" guys tell you :-)

Fred



-Original Message-
From: Steve O'Hara [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 21, 2006 7:37 AM
To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Subject: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java



I did loads of research on this and even tinkered with a c to Java
converter, which got me a little bit further forward.  However, I
realised that I would be facing a huge effort to create the


code base


and then have to support it within our projects.  So


despite being an


SQLite zealot, I had to reluctantly nail my colours to one of the
existing Java tools.

I chose HSQLDB, after trying out most of the others, this


was the only


one that got close to the file distribution format of SQLite i.e.
database in a file.  It took quite a bit of tinkering to


get the right


mix of CACHED and MEMORY tables so that performance on start-up was
good.  Also, I had terrible trouble with mass imports causing memory
(what a surprise - Java) problems and it took a good few runs
to get it
to properly index etc.  Also, I had to be much more


specific about the


column definitions than with SQLite, otherwise my database


files grew


horribly.  Also, you can only interact with HSQLDB via


JDBC, not a big


problem in Java obviously.  Performance was nowhere near as good as
SQLite.

However, the upside is that HSQLDB is free, simple to 

Re: [sqlite] Version 3.3.0 (alpha)

[drh]

Brett Wilson <[EMAIL PROTECTED]> wrote:
> Does anybody know if there anything special we have to do to get the
> new boolean optimization? Does it apply to any 0/1 integer values you
> put in a cell, or does the column have to be declared as BOOLEAN?
> 


If the column type is "TEXT" or "VARCHAR", then when you try
to insert the 1 or 0 it will get changed into a "1" or "0".
But otherwise, it should not matter what the column type is.
Storing a 0 or 1 will use the new encoding.

Note also that if the column type is "REAL", and you insert
a 0.0 or 1.0, that value is stored using the new boolean
encoding too.  REAL values are stored as integers if they 
can be, then converted back to REAL when read back out of
the file.  This is because integers normally use less disk 
space.
--
D. Richard Hipp <[EMAIL PROTECTED]>

RE: [sqlite] Writing/reading blobs

[Robert Simpson]

> -Original Message-
> From: Robert Bielik [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, January 22, 2006 9:33 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Writing/reading blobs
> 
> I think he has more or less abandoned that project. So I've 
> had to tweak 
> the ODBC driver to work with
> blobs anyway (because the 0.65 ODBC driver could only handle text).
> 
> I've tweaked the SQLGetData to retrieve a blob correctly, 
> haven't tried it 
> yet with large data tho.. but
> not SQLPutData yet (at least not sufficiently). So you mean 
> I'd alloc a 
> buffer in SQLBindParameter
> (where length of data is given), then fill that buffer in 
> SQLPutData (til 
> its done), and then pass it to SQLite?

Something to that effect would probably work, provided you knew in advance
what size the blob would be.

Robert

Re: [sqlite] Writing/reading blobs

[Robert Bielik]

I think he has more or less abandoned that project. So I've had to tweak 
the ODBC driver to work with

blobs anyway (because the 0.65 ODBC driver could only handle text).

I've tweaked the SQLGetData to retrieve a blob correctly, haven't tried it 
yet with large data tho.. but
not SQLPutData yet (at least not sufficiently). So you mean I'd alloc a 
buffer in SQLBindParameter
(where length of data is given), then fill that buffer in SQLPutData (til 
its done), and then pass it to SQLite?


/R

On Sun, 22 Jan 2006 08:33:15 -0700, Robert Simpson <[EMAIL PROTECTED]> 
wrote:



-Original Message-
From: Robert Bielik [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 22, 2006 8:17 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] Writing/reading blobs

Hi all,

I'm using SQLite3 via the SQLite ODBC wrapper. Amongst other
things I need
to store large blobs. When using ODBC this means several calls to
SQLPutData/SQLGetData. I've read the docs and it seems that
SQLite doesn't
support this. Is this in planning, and/or can someone well
versed in the
code of SQLite say if this is doable?


This is a question to ask the author of the ODBC driver.  Faking
SQLGetData()'s stream-like fetch is easy, but it's a little hard to fake
SQLPutData().  SQLite expects the entire blob to be assigned or 
fetched.  If
you're working with massive blobs, be aware SQLite retrieves them from 
disk
in their entirety so you need to have to enough RAM to hold an entire 
row of

such a table.

Robert

[sqlite] Writing/reading blobs

[Robert Bielik]

Hi all,

I'm using SQLite3 via the SQLite ODBC wrapper. Amongst other things I need 
to store large blobs. When using ODBC this means several calls to 
SQLPutData/SQLGetData. I've read the docs and it seems that SQLite doesn't 
support this. Is this in planning, and/or can someone well versed in the 
code of SQLite say if this is doable?


Regards,
/Rob

RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

[Fred Williams]

You points are understood.  But I've always attempted to use a hammer
for a nail and a screwdriver for a screw.  This extra effort always
produces a much cleaner and professional result.

Good clients know that response time is money and resources they spend
every day and at every seat.  Proper software development is a high cost
one time event.  I have had occasion to see code I have written running
five plus years after implementation.  In that time migrated across
three platforms.

Fred

> -Original Message-
> From: Steve O'Hara [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 22, 2006 4:06 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java
>
>
> You're right to a certain extent, but the point I was trying
> to address
> was the ideal of being able to use an SQLite database from a
> variety of
> toolsets and environments natively.  If you've ever written JNI you'll
> know why this is a pain and a Java only implementation would be sweet.
>
> Also, not all SQL engines work the same way and I'm certain HSQLD is
> slower than SQLite architecturally, not because it's implemented in
> Java.  After all, there is a non-free variant of HSQLDB
> (HyperXtremSQL)
> written in Java by the same author that is 50% faster - he didn't get
> that by tweaking the code, more like re-architecting the storage.
>
> The language is just a tool, a way of describing a solution to a
> machine.  The judgement of performance etc of a language is a little
> specious because it implies a generalisation of how the language is
> implemented on a particular platform.  I've learned to like
> Java because
> I've got a beautiful development environment (intelliJ IDEA) and in my
> professional life, speed/quality of development is more important than
> response times.  My clients would prefer to spend more money
> on hardware
> than on consultancy - who can blame them.
>
> Steve
>
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:sqlite-users-return-10034-sohara=pivotal-solutions.co.
> [EMAIL PROTECTED]
> org] On Behalf Of Fred Williams
> Sent: 21 January 2006 15:52
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java
>
> I think if you will closely read you own analysis of your efforts you
> will realize that all of the "down side" issues you have enumerated
> relate directly to the implementation language and not the database or
> its structure.  In Java there is no such thing as AnythingLite, IMHO.
> Java, like so many other languages has grown well beyond its initial
> intent, small, simple applets imbedded on a web page.
>
> With all of our advances in programming we still have not evolved that
> "perfect" language, and most likely never will.  I spite of what those
> "C" guys tell you :-)
>
> Fred
>
> > -Original Message-
> > From: Steve O'Hara [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, January 21, 2006 7:37 AM
> > To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
> > Subject: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java
> >
> >
> >
> > I did loads of research on this and even tinkered with a c to Java
> > converter, which got me a little bit further forward.  However, I
> > realised that I would be facing a huge effort to create the
> code base
> > and then have to support it within our projects.  So
> despite being an
> > SQLite zealot, I had to reluctantly nail my colours to one of the
> > existing Java tools.
> >
> > I chose HSQLDB, after trying out most of the others, this
> was the only
> > one that got close to the file distribution format of SQLite i.e.
> > database in a file.  It took quite a bit of tinkering to
> get the right
> > mix of CACHED and MEMORY tables so that performance on start-up was
> > good.  Also, I had terrible trouble with mass imports causing memory
> > (what a surprise - Java) problems and it took a good few runs
> > to get it
> > to properly index etc.  Also, I had to be much more
> specific about the
> > column definitions than with SQLite, otherwise my database
> files grew
> > horribly.  Also, you can only interact with HSQLDB via
> JDBC, not a big
> > problem in Java obviously.  Performance was nowhere near as good as
> > SQLite.
> >
> > However, the upside is that HSQLDB is free, simple to deploy, has
> > standalone/server/servlet/in-memory deployment versions and is
> > reasonably perfomant.
> >
> > Hope this helps,
> >
> > Steve
> >
> > p.s. I'd still prefer a Java SQLite but there you are
> >
> >
> >
> > -Original Message-
> > From:
> > [EMAIL PROTECTED]
> > [mailto:sqlite-users-return-9982-sohara=pivotal-solutions.co.u
> [EMAIL PROTECTED]
> rg] On Behalf Of Ran
> Sent: 19 January 2006 14:13
> To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
> Subject: [RBL] Re: [sqlite] Sqlite and Java
>
> If I am not mistaken, the following thread might be relevant:
> http://www.mail-archive.com/sqlite-users@sqlite.org/msg11005.html
>
> Ran
>
> On 1/19/06, Nilo Paim <[EMAIL 

RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

[Steve O'Hara]

You're right to a certain extent, but the point I was trying to address
was the ideal of being able to use an SQLite database from a variety of
toolsets and environments natively.  If you've ever written JNI you'll
know why this is a pain and a Java only implementation would be sweet.

Also, not all SQL engines work the same way and I'm certain HSQLD is
slower than SQLite architecturally, not because it's implemented in
Java.  After all, there is a non-free variant of HSQLDB  (HyperXtremSQL)
written in Java by the same author that is 50% faster - he didn't get
that by tweaking the code, more like re-architecting the storage.

The language is just a tool, a way of describing a solution to a
machine.  The judgement of performance etc of a language is a little
specious because it implies a generalisation of how the language is
implemented on a particular platform.  I've learned to like Java because
I've got a beautiful development environment (intelliJ IDEA) and in my
professional life, speed/quality of development is more important than
response times.  My clients would prefer to spend more money on hardware
than on consultancy - who can blame them.

Steve

-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Fred Williams
Sent: 21 January 2006 15:52
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

I think if you will closely read you own analysis of your efforts you
will realize that all of the "down side" issues you have enumerated
relate directly to the implementation language and not the database or
its structure.  In Java there is no such thing as AnythingLite, IMHO.
Java, like so many other languages has grown well beyond its initial
intent, small, simple applets imbedded on a web page.

With all of our advances in programming we still have not evolved that
"perfect" language, and most likely never will.  I spite of what those
"C" guys tell you :-)

Fred

> -Original Message-
> From: Steve O'Hara [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 21, 2006 7:37 AM
> To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
> Subject: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java
>
>
>
> I did loads of research on this and even tinkered with a c to Java
> converter, which got me a little bit further forward.  However, I
> realised that I would be facing a huge effort to create the code base
> and then have to support it within our projects.  So despite being an
> SQLite zealot, I had to reluctantly nail my colours to one of the
> existing Java tools.
>
> I chose HSQLDB, after trying out most of the others, this was the only
> one that got close to the file distribution format of SQLite i.e.
> database in a file.  It took quite a bit of tinkering to get the right
> mix of CACHED and MEMORY tables so that performance on start-up was
> good.  Also, I had terrible trouble with mass imports causing memory
> (what a surprise - Java) problems and it took a good few runs
> to get it
> to properly index etc.  Also, I had to be much more specific about the
> column definitions than with SQLite, otherwise my database files grew
> horribly.  Also, you can only interact with HSQLDB via JDBC, not a big
> problem in Java obviously.  Performance was nowhere near as good as
> SQLite.
>
> However, the upside is that HSQLDB is free, simple to deploy, has
> standalone/server/servlet/in-memory deployment versions and is
> reasonably perfomant.
>
> Hope this helps,
>
> Steve
>
> p.s. I'd still prefer a Java SQLite but there you are
>
>
>
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:sqlite-users-return-9982-sohara=pivotal-solutions.co.u
[EMAIL PROTECTED]
rg] On Behalf Of Ran
Sent: 19 January 2006 14:13
To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Subject: [RBL] Re: [sqlite] Sqlite and Java

If I am not mistaken, the following thread might be relevant:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg11005.html

Ran

On 1/19/06, Nilo Paim <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Does anybody here knows something about a port of sqlite to java?
>
> Please, note that I'm not talking about java calling sqlite via JNI,
but
> about a real rewrite of sqlite using java. Obviously, a second step
> would be the writing of a JDBC driver.
>
> Would be useful that port?
>
> Comments? Suggestions?
>
> Thanks to all.
>
> Nilo
> Porto Alegre - Brasil
>