firebird-net-provider — All about development of the MS .Net provider

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[Jojakim S. <JS...@de...>]

> > What about building a similar solution: BeginTransaction(), Commit(bool
> > retaining) or Rollback(bool retaining). Standard Commit() / Rollback()
> > call
> > these methods with retaining=false. The only thing, I'm not
> sure about is,
> > whether it should be necessary to call BeginTransaction() after a
> > Commit/Rollback(retaining=true). I tend to prefer not to call
> > BeginTransaction() again.
>
>
> I have no problem in add these two methods as overloaded methods for
> Commit and Rollback but possible can be better to implement savepoints.

But as far as I know, savepoint and retaining transactions are not the same.
If you commit retaining, you have no possibility to rollback what you have
committed, only the transaction environment (=the snapshot of row versions)
remains within the new transaction.

A savepoint is a point within an overall transaction (I don't know the exact
implementation in firebird 1.5, so I speak with the MSSQLServer knowledge),
you can
BeginTransaction("Point0");
DBOps...
Save("Point1");
DBOps...
Save("Point2");
DBOps...
Rollback("Point1");   // Cancels all DBOps made since Save("Point1")
DBOps...
Save("OtherThings");
Rollback("Point0");   // Cancels complete transaction

So if firebird 1.5 has savepoints, perhaps we need both methods.
To propose some good method names and signatures I have to look at firebird
1.5 docu/source to inform myself about the savepoints implemented there.

-- Joja

[Firebird-net-provider] Re: New Setup for your .Net Provider

[<car...@te...>]

Hello:

 > Dear Mr. Guzmán Álvarez,

Mr is not needed :)

 > I wanted  to tell you how much I appreciate your .Net Provider for
 > Firebird. I'm testing your solution and to become faster I created a
 > setup. I used Free Ghost Installer. This installer also works under the
 > .Net Framework. I'm attaching my setup and the configuration property 
file.


This is very good, thanks very much

 >
 > If you want to, when you release the next version, I can  send you the
 > new setup.  Thank you very much for your work,


I will try to release next version using an installer, the free version 
of Ghost Installer can be a good option :) thanks very much.




Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Re: AW: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Hello:

> I propose the standard behavior should be like the MS providers.
> But what do you think about the normal/retaining problem?
>
> I looked at the documentation of the SqlTransaction class for MSSQLServer.
> They implemented savepoints within transactions by introducing a
> non-IDbTransaction method Save(string savepoint) and overloaded Commit and
> Rollback with version that accept these savepoints. However standard
> behavior is BeginTransaction(), Commit() or Rollback().


As i know savepoints are implemented on FB 1.5, can be a good idea to 
implement a Save(string savepointName) on FbTransaction ??

> What about building a similar solution: BeginTransaction(), Commit(bool
> retaining) or Rollback(bool retaining). Standard Commit() / Rollback() 
> call
> these methods with retaining=false. The only thing, I'm not sure about is,
> whether it should be necessary to call BeginTransaction() after a
> Commit/Rollback(retaining=true). I tend to prefer not to call
> BeginTransaction() again.


I have no problem in add these two methods as overloaded methods for 
Commit and Rollback but possible can be better to implement savepoints.

Comments are welcome on this issue :)

> I included the changes from yesterday as diff -u now.


Thanks very much this makes more easy to me to apply patches :) .



Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Re: [Firebird-net-provider] firebird-net-provider now available from news.atkin.com

[<car...@te...>]

Hello:

> The firebird-net-provider newslist is now available as a 'news' group from
> news.atkin.com.


Good news, thanks very much for this :)



Best regards

Carlos Guzmán Álvarez
Vigo-Spain

AW: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[Jojakim S. <JS...@de...>]

I propose the standard behavior should be like the MS providers.
But what do you think about the normal/retaining problem?

I looked at the documentation of the SqlTransaction class for MSSQLServer.
They implemented savepoints within transactions by introducing a
non-IDbTransaction method Save(string savepoint) and overloaded Commit and
Rollback with version that accept these savepoints. However standard
behavior is BeginTransaction(), Commit() or Rollback().

What about building a similar solution: BeginTransaction(), Commit(bool
retaining) or Rollback(bool retaining). Standard Commit() / Rollback() call
these methods with retaining=false. The only thing, I'm not sure about is,
whether it should be necessary to call BeginTransaction() after a
Commit/Rollback(retaining=true). I tend to prefer not to call
BeginTransaction() again.

I included the changes from yesterday as diff -u now.

Greetings, Joja

> -----Ursprüngliche Nachricht-----
> Von: fir...@li...
> [mailto:fir...@li...]Im Auftrag von
> Carlos Guzmán Álvarez
> Gesendet am: Donnerstag, 21. November 2002 18:35
> An: Firebird .Net Provider; Jojakim Stahl
> Betreff: Re: [Firebird-net-provider] Normal or retained commit/rollback
> of transactions
>
> Hello:
>
>  >>Thanks very much ;), i´m seeing now how other providers manage this
>  >>issue, can you send the patches with diff -u please.
>
> I´m testing this and microsoft providers throw exception if you make
> anything like this:
>
> 	...
> 	myTrans.Rollback();	<-- this make connection to be
> capable 							of
> begin a new transaction
> 	myTrans.Commit();	<-- This throw InvalidOperationException
> 	...
>
> or
> 	...
> 	myTrans.Commit();	<-- this make connection to be
> capable 							of
> begin a new transaction
> 	myTrans.Rollback();	<-- This throw InvalidOperationException
> 	...
>
>
>
> I can made the changes needed for work if there are no opinions against
> it :)
>
>
>
>
> Best regards
> Carlos Guzmán Álvarez
> Vigo-Spain
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>

[Firebird-net-provider] firebird-net-provider now available from news.atkin.com

[Mark O'D. <mar...@cy...>]

Hi

The firebird-net-provider newslist is now available as a 'news' group from
news.atkin.com.

Cheers

Mark

[Firebird-net-provider] Test2

[Mark O'D. <mar...@cy...>]

Test2

[Firebird-net-provider] Test

[Mark O'D. <mar...@cy...>]

Test

[Firebird-net-provider] Transaction changes

[<car...@te...>]

Hello:


I have made the changes for made transactions work as on other
providers, i think this is the best way for make this compatible
with other existing providers, but i don´t have it updated yet.


Comments are welcome on this issue.





Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Hello:

 >>Thanks very much ;), i´m seeing now how other providers manage this
 >>issue, can you send the patches with diff -u please.

I´m testing this and microsoft providers throw exception if you make 
anything like this:

	...
	myTrans.Rollback();	<-- this make connection to be capable 							of 
begin a new transaction
	myTrans.Commit();	<-- This throw InvalidOperationException
	...

or
	...
	myTrans.Commit();	<-- this make connection to be capable 							of 
begin a new transaction
	myTrans.Rollback();	<-- This throw InvalidOperationException
	...



I can made the changes needed for work if there are no opinions against 
it :)




Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Jojakim Stahl wrote:

 > Hello!
 >
 > A got the new CVS version and had problems to call
 > FbConnection.BeginTransaction() a second time after disposing the
 > FbTransaction-object returned by the first call.
 > I studied code and found that FbTransaction.Dispose() doesn't reset the
 > active transaction object of the connection. Due to the simple test for
 > activeTxn != null when calling FbConnection.BeginTransaction() the second
 > call throws.



I make this after see documentation of SqlClient, OleDb, And Odbc .Net 
providers by Microsoft that doesn´t allow parallel transactions, i want 
to make this the most conmpaitble as possible with other .net providers.

 > I added an internal property to FbTransaction to query the transactions
 > state and extended the test in FbConnection.BeginTransaction() to 
check the
 > state.



Thanks very much ;), i´m seeing now how other providers manage this 
issue, can you send the patches with diff -u please.



Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Re: [Firebird-net-provider] Calling BeginTransaction multiple times

[<car...@te...>]

Jojakim Stahl wrote:

> Hello!
>
> A got the new CVS version and had problems to call
> FbConnection.BeginTransaction() a second time after disposing the
> FbTransaction-object returned by the first call.
> I studied code and found that FbTransaction.Dispose() doesn't reset the
> active transaction object of the connection. Due to the simple test for
> activeTxn != null when calling FbConnection.BeginTransaction() the second
> call throws.


I make this after see documentation of SqlClient, OleDb, And Odbc .Net 
providers by Microsoft that doesn´t allow parallel transactions, i want 
to make this the most conmpaitble as possible with other .net providers.

> I added an internal property to FbTransaction to query the transactions
> state and extended the test in FbConnection.BeginTransaction() to 
> check the
> state.


Thanks very much ;), i´m seeing now how other providers manage this 
issue, can you send the patches withh diff -u please.



Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Hello:

 > I studied code of FbTransaction and found that Rollback() and 
Commit() use
 > the *_retaining version for committing / rolling back transactions. 
After a
 > retained commit/rollback automatically a "new" transaction is started,
 > indicated by a transaction state of TxnState.TRANSACTION_STARTED. Now, a
 > call to FbConnection.BeginTransaction() failes.



I make this after see documentation of SqlClient, OleDb, And Odbc .Net 
providers by Microsoft that doesn´t allow parallel transactions, i want 
to make this the most conmpaitble as possible with other .net providers.

 > But this is, in my opinion, not what the normal developer expect 
(compared
 > to other RDBMS). Also, the retained commit/rollback preserves the 
snapshot
 > of the former transaction, which again may not result in a behavior
 > comparable to other RDBMS.
 >
 > I propose to introduce a property to the connection and/or transaction
 > objects to set the commit/rollback mode to retaining or normal. In normal
 > mode, the Commit()/Rollback() methods must call the standard
 > GDS-transaction-functions and set the TxnState to TxnState.NOTRANSACTION.
 > For retaining mode, the behavior is acceptable like it is now.



This can be a good idea i can see how other providers manage commiting 
and rollbacking transactions.




Best regards
Carlos Guzmán Álvarez
Vigo-Spain

 >
 > Just my thoughts on that topic, any comments welcome.
 >
 > -- Joja
 >
 >
 >
 > -------------------------------------------------------
 > This sf.net email is sponsored by:ThinkGeek
 > Welcome to geek heaven.
 > http://thinkgeek.com/sf
 > _______________________________________________
 > Firebird-net-provider mailing list
 > Fir...@li...
 > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
 >

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Hello:
Hello!

> I studied code of FbTransaction and found that Rollback() and Commit() use
> the *_retaining version for committing / rolling back transactions. 
> After a
> retained commit/rollback automatically a "new" transaction is started,
> indicated by a transaction state of TxnState.TRANSACTION_STARTED. Now, a
> call to FbConnection.BeginTransaction() failes.


I make this after see documentation of SqlClient, OleDb, And Odbc .Net 
providers by Microsoft that doesn´t allow parallel transactions, i want 
to make this the most conmpaitble as possible with other .net providers.

> But this is, in my opinion, not what the normal developer expect (compared
> to other RDBMS). Also, the retained commit/rollback preserves the snapshot
> of the former transaction, which again may not result in a behavior
> comparable to other RDBMS.
>
> I propose to introduce a property to the connection and/or transaction
> objects to set the commit/rollback mode to retaining or normal. In normal
> mode, the Commit()/Rollback() methods must call the standard
> GDS-transaction-functions and set the TxnState to TxnState.NOTRANSACTION.
> For retaining mode, the behavior is acceptable like it is now.


This can be a good idea i can see how other providers manage commiting 
and rollbacking transactions.




Best regards
Carlos Guzmán Álvarez
Vigo-Spain

>
> Just my thoughts on that topic, any comments welcome.
>
> -- Joja
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>

[Firebird-net-provider] Normal or retained commit/rollback of transactions

[Jojakim S. <JS...@de...>]

Hello!
I studied code of FbTransaction and found that Rollback() and Commit() use
the *_retaining version for committing / rolling back transactions. After a
retained commit/rollback automatically a "new" transaction is started,
indicated by a transaction state of TxnState.TRANSACTION_STARTED. Now, a
call to FbConnection.BeginTransaction() failes.

But this is, in my opinion, not what the normal developer expect (compared
to other RDBMS). Also, the retained commit/rollback preserves the snapshot
of the former transaction, which again may not result in a behavior
comparable to other RDBMS.

I propose to introduce a property to the connection and/or transaction
objects to set the commit/rollback mode to retaining or normal. In normal
mode, the Commit()/Rollback() methods must call the standard
GDS-transaction-functions and set the TxnState to TxnState.NOTRANSACTION.
For retaining mode, the behavior is acceptable like it is now.

Just my thoughts on that topic, any comments welcome.

-- Joja

[Firebird-net-provider] Calling BeginTransaction multiple times

[Jojakim S. <JS...@de...>]

Hello!

A got the new CVS version and had problems to call
FbConnection.BeginTransaction() a second time after disposing the
FbTransaction-object returned by the first call.
I studied code and found that FbTransaction.Dispose() doesn't reset the
active transaction object of the connection. Due to the simple test for
activeTxn != null when calling FbConnection.BeginTransaction() the second
call throws.

I added an internal property to FbTransaction to query the transactions
state and extended the test in FbConnection.BeginTransaction() to check the
state.

-- Joja

Re: [Firebird-net-provider] NULL Parameter values for textual data-types / Encoding questions

[<car...@te...>]

Hello:


I have updated more changes for make WriteSQLDatum to expect array of 
bytes instead of strings, and i will try to add to FbConnection a new 
internal property for get the correct encoding, anything like this:

private Encoding encoding;

internal Encoding Encoding
{
	get{return encoding;}
}


this will be updated on FbConnection.Open.




Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Re: [Firebird-net-provider] NULL Parameter values for textual data-types / Encoding questions

[<car...@te...>]

Hello:

I have updated some changes to the CVS for triying to get better 
encoding support, only in WriteSQLData at this moment if this works well
i can make the same for ReadSQLData, can you test it please??



Best regards
Carlos Guzmán Álvarez
Vigo-Spain

[Firebird-net-provider] NULL Parameter values for textual data-types / Encoding questions

[Jojakim S. <JS...@de...>]

I have a question regarding the FirebirdSql.Data.NGDS.GDS.FixNull(XSQLVAR
xsqlvar) method:

When executing a statement with an input parameter of value DBNull and type
FbType.VarChar or FbType.Char the FixNull function sets up (as I understand
it) a dummy (null) value which is transfered to the server. The actual
indication that the parameter is DBNull is done by setting xsqlvar.sqlind
= -1.

		private void FixNull(XSQLVAR xsqlvar)
		{
			if ((xsqlvar.sqlind == -1) && (xsqlvar.sqldata == null))
			{
				switch (xsqlvar.sqltype & ~1)
				{
					case SQL_TEXT:
						xsqlvar.sqldata = new byte[xsqlvar.sqllen];
						break;

					case SQL_VARYING:
						xsqlvar.sqldata = new byte[0];
						break;

Why now in FixNull the dummy value used for SQL_TEXT and SQL_VARYING are
arrays of bytes? and not strings? As in WriteSQLDatum the xsqlvar.sqldata
value is cast to a string, an exception is the result.

I did a quick-test and assigned xsqlvar.sqldata = string.Empty in the
SQL_VARYING case, and all seems to work well now.

But I'm not sure for the SQL_TEXT case. Is it required to always write the
exact amount of bytes for a CHAR column? What about a column with
UNICODE_FSS encoding: Do I have to write the amount of charachters declared
in the table creation statement, or the amount of octets reserved for the
column (for UNICODE_FSS this is 3 times the declared value).

If the latter is the case, I think the way how WriteSQLDatum works isn't
correct, too:

case SQL_TEXT:
	if(((string)sqldata).Length != xsqlvar.sqllen)
	{
		throw new GDSException(isc_rec_size_err);
	}
	db.output.WriteOpaque(
			Encoding.Default.GetBytes((string)sqldata),
			xsqlvar.sqllen);
	break;

case SQL_VARYING:
	if(((string)sqldata).Length > xsqlvar.sqllen)
	{
		throw new GDSException(isc_rec_size_err);
	}
	db.output.WriteInt(((string)sqldata).Length);
	db.output.WriteOpaque(
			Encoding.Default.GetBytes((string)sqldata),
			((string)sqldata).Length);
	break;

While debugging I found that xsqlvar.sqllen contains the amnout of octets
reserved for the columns data, for textual columns of UNICODE_FSS encoding
this is 3 times the declared charachter amount. So comparing
((string)sqldata).Length with xsqlvar.sqllen as a condition to generate
exceptions isn't correct.

Aswell, just writing out the bytes that result from
Encoding.Default.GetBytes() is not correct because a string with just 10
ascii chars in the range 0 to 127 results in a byte array of length 10. But
for the SQL_TEXT case WriteOpaque is directed to write out 30 bytes.

For the SQL_VARYING case, if you write a unicode char with a UTF-8 mapping
of 3 bytes, you only write 1 byte, as string.Length will return 1.

Another thing is, that the usage of Encoding.Default should be replaced by
Encodings.GetFromFirebirdEncoding(connection.Charset).

So the key points are:
- When outputting a string, is it neccessary to output the amount of
charachters or the amout of bytes the string needs in the connections
encoding?
- Use the correct encoding!
- Remove inconsistencies within the type of data stored in xsqlvar.sqldata
for textual data types. Current State: ReadSQLDatum uses the byte[] version,
byte[] to string conversion is done in FbResultSet. WriteSQLDatum expects
strings. FixNull requires WriteSQLDatum to expect byte[].

Excuse the long message. Any comments welcome. I would take the time to
correct the behavior after an agreement on the what-is-correct is found.

Thanx,
  Joja

[Firebird-net-provider] ANN: Reference to the Firebird .Net Data Provider on Mono platform web site

[<car...@te...>]

Hello:

The Firebird .Net Data Provider have a reference on Mono platform web
site since a few days, you can see the reference at:

     http://www.go-mono.com/firebird.html


What is Mono?

The Mono Project is an open development initiative sponsored by Ximian
that is working to develop an open source, Unix version of the Microsoft
.NET development platform. Its objective is to enable Unix developers to
build and deploy cross-platform .NET Applications. The project will
implement various technologies developed by Microsoft that have now been
submitted to the ECMA for standardization.


The URL of the Mono project is:

     http://www.go-mono.com


Note about the provider on Mono:

The provider can be builded using Mono ( using CVS sources of both
projects ), i have make a few tests with the provider with Mono on Linux
Red Hat 8 and it´s working quite well.



Best regards
Carlos Guzmán Álvarez
Vigo-Spain

[Firebird-net-provider] ANN: Reference to the Firebird .Net Data Provider on Mono platform web site

[<car...@te...>]

Hello:

The Firebird .Net Data Provider have a reference on Mono platform web
site since a few days, you can see the reference at:

	http://www.go-mono.com/firebird.html


What is Mono?

The Mono Project is an open development initiative sponsored by Ximian
that is working to develop an open source, Unix version of the Microsoft
.NET development platform. Its objective is to enable Unix developers to
build and deploy cross-platform .NET Applications. The project will
implement various technologies developed by Microsoft that have now been
submitted to the ECMA for standardization.


The URL of the Mono project is:

	http://www.go-mono.com


Note about the provider on Mono:

The provider can be builded using Mono ( using CVS sources of both
projects ), i have make a few tests with the provider with Mono on Linux
Red Hat 8 and it´s working quite well.



Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Re: [Firebird-net-provider] Datacontrols

[Christoph D. <cd...@ar...>]

Here is a useful web page on the subject:

http://samples.gotdotnet.com/quickstart/winforms/doc/WinFormsData.aspx


Christoph

----- Original Message ----- 
From: "Sandeep Chandra" <sa...@cf...>
To: <fir...@li...>
Sent: Wednesday, November 20, 2002 5:22 AM
Subject: [Firebird-net-provider] Datacontrols


> I'm new to VS.Net, and I'm trying to link a Textbox to dataset (as in
> Delphi). How do I do this using FB.Net components.
> 
> Regards
> 
> Sandeep
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing 
> your web site with SSL, click here to get a FREE TRIAL of a Thawte 
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

[Firebird-net-provider] Datacontrols

[Sandeep C. <sa...@cf...>]

I'm new to VS.Net, and I'm trying to link a Textbox to dataset (as in
Delphi). How do I do this using FB.Net components.

Regards

Sandeep

[Firebird-net-provider] Re: CVS Sources

[<car...@te...>]

Hello:

> there was no problems with builds... except one...
> I downloaded sourcer builded it and rune, but there was PInvoke exception
> every FbConnection.Open()... i was working on it 4 hours, but i was 
> not able
> ot make it work...
> And where was problem??? Probably you commited not buildable sources to
> CVS... evening i went home, downloaded new sources and it was working
> correctlly... PLEASE TRY TO COMMIT ONLY COMPILABLE SOURCES :-) From now i
> will work on tests hard, so dont make me crazy with not compillable :-)


Ok, sorry, i always try to make cvs sources compilables :))

>
> Large buffers work... tested on aprox. 300 tests and different 
> databases...
> Biggest was 2Gb database with 32k varchar fields and "select * from" 
> worked
> correctlly all times...


Ok, thanks very much for this.

>
> ConnectionPooling was working too without problems. Performance is 
> good, but
> it is still not screaming (but it is still excelent)... And i think, 
> that i
> found there rare conditions there... I will check sources if there is
> complete locking done...


There can be some problems with detaching to databases when the 
application ends, i´m viewing how the gc works for trying to solve this.

> Can you advice me how to debug memory leaks in .NET, becouse my 
> program was
> growing in memory significantly even i called GC manually...

I´m viewing this too :))))

See this (can be helful, i´m going to view it too):

http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx
http://msdn.microsoft.com/msdnmag/issues/1200/gci2/default.aspx


Best regards
Carlos Guzmán Álvarez
Vigo-Spain

[Firebird-net-provider] Re: CVS Sources

[Pavol S. - P. <pa...@st...>]

hi,

there was no problems with builds... except one...
I downloaded sourcer builded it and rune, but there was PInvoke exception
every FbConnection.Open()... i was working on it 4 hours, but i was not able
ot make it work...
And where was problem??? Probably you commited not buildable sources to
CVS... evening i went home, downloaded new sources and it was working
correctlly... PLEASE TRY TO COMMIT ONLY COMPILABLE SOURCES :-) From now i
will work on tests hard, so dont make me crazy with not compillable :-)

Large buffers work... tested on aprox. 300 tests and different databases...
Biggest was 2Gb database with 32k varchar fields and "select * from" worked
correctlly all times...

ConnectionPooling was working too without problems. Performance is good, but
it is still not screaming (but it is still excelent)... And i think, that i
found there rare conditions there... I will check sources if there is
complete locking done...

Can you advice me how to debug memory leaks in .NET, becouse my program was
growing in memory significantly even i called GC manually...

THANX
p.

----- Original Message -----
From: "Carlos Guzmán Álvarez" <car...@te...>
To: <pa...@st...>
Sent: Monday, November 18, 2002 10:05 PM
Subject: CVS Sources


> Hello:
>
>
> Finally you will be capable of get the cvs sources and build it??, you
> need help??. If you buid it, have you tested the problem with the large
> varchars??
>
>
>
> Best regards
> Carlos Guzmán Álvarez
> Vigo-Spain
>