Huge memory consumed with myOdbc and VB.NET

------_=_NextPart_001_01C66E89.2CDD310A
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

Hi All!

When using MyOdbc3.51.12 with VB.net(1.1) and filling a dataset from
table all available memory get consumed after a couple of 500 queries.

The problem only arises with tables that contains a huge amount of
records(>100000) and that leads me to the conclusion that the whole
table for some reason gets into odbcmemory, and performance is also
lousy.

The datatable in the dataset only contains the row from query (SELECT *
from XXX Where ID=3D'1') and ID is primary KEY.

=20

The problem only arises when Dataadapter.MissingSchemaAction =3D
MissingSchemaAction.AddWithKey is used in dataadapter, without that
line the problem does not show!

=20

The program runs without problem on 2003-server/wts and ordinary window
clients.

The problemserver is an 2003 windows server std edition SP1 citrix
metaframe (4.0.17-max-debug /odbc 3.51.12)

=20

The program exits after 500 queries on dataadapter.fill with exception,
"Object reference not set to an instance of an object" and about 1.5 GB
memory is consumed!

=20

Any help on this issue is appreciated!

=20

Regards

Patrik

=20

Vb-code:

Imports System.Data.Odbc

=20

Module Module1

=20

Private cn As OdbcConnection

Private Dataadapter As OdbcDataAdapter

=20

Sub Main()

=20

Dim ds As New DataSet

Dim sql As String

Dim count as integer =3D 10000

cn =3D New OdbcConnection("DSN=3Dtest")

sql =3D "SELECT * FROM xxx where id=3D '1'"

Try

cn.Open()

Dataadapter =3D New OdbcDataAdapter(sql, cn)

Dataadapter.MissingSchemaAction =3D
MissingSchemaAction.AddWithKey '*** When removing this line the isue
doesn't arise!!! ***

Catch ex As Exception

Console.WriteLine(ex.Message)

Console.ReadLine()

End

End Try

=20

Do

Try

Dataadapter.Fill(ds, "table")

Catch ex As Exception

Console.WriteLine("Count:" & Count & vbCrLf &
ex.Message)

'"Object reference not set to an instance of an
object" after about 500 queries"

Exit Do

End Try

'Do som work!

=20

If Count Mod 100 =3D 0 Then

Console.Write(Count & ",(" & ds.Tables(0).Rows.Count &
")")

End If

ds.Tables("xxx").Clear()

Count -=3D 1

Loop Until Count <=3D 0

End Sub

=20

End Module

=20

=20

=20

=20


------_=_NextPart_001_01C66E89.2CDD310A--

RE: Huge memory consumed with myOdbc and VB.NET

> Vb-code:

Please send code per attachment - mailers tend to mangle it.

Alternatively keep it below 80 characters or use a mailer that
supports format=3Dflowed.

> Imports System.Data.Odbc
> Module Module1
> Private conn As OdbcConnection
> Private adapter As OdbcDataAdapter
> Sub Main()
> Dim ds As New DataSet
> Dim sql As String
> Dim count As Integer =3D 10000
> conn =3D New OdbcConnection("DSN=3Dtest")
> sql =3D "SELECT * FROM xxx where id=3D'1'"
> Try
> conn.Open()
> adapter =3D New OdbcDataAdapter(sql, conn)
> adapter.MissingSchemaAction =3D MissingSchemaAction.AddWithKey
> ' When removing above line the issue doesn't arise!
> Catch ex As Exception
> Console.WriteLine(ex.Message)
> Console.ReadLine()
> End
> End Try

Your try..catch structure looks weird.

Below, you actually attempt to fill the dataadapter
whether you successfully connect to the database or not.

Is this intentional?

> Do
> Try
> adapter.Fill(ds, "table")

You're filling into a table named "table"...

> Catch ex As Exception
> Console.WriteLine("Count: {0}\r\n{1}", count, ex.Message)
> ' "Object reference not set to an instance of an object"
> ' after about 500 queries
> Exit Do
> End Try
> ' Do some work!
> If Count Mod 100 =3D 0 Then
> Console.Write("{0}, ({1})",Count,ds.Tables(0).Rows.Count)
> End If
> ds.Tables("xxx").Clear()

You're trying to delete a table that does not exist.
You've explicitly named the table "table" earlier,
so you'll get a null reference exception here in the
first execution of your loop.

Also, could you please post your database schema
(SHOW CREATE TABLE xxx)? The definition of primary keys will
have an effect on which code path your test case follows. You
mention that you use "id" as a primary key, but is it actually
defined as such in your database?

> Count -=3D 1
> Loop Until Count <=3D 0
> End Sub
> End Module


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=3Dgcdmo-myodbc@m.gmane.o rg

RE: Huge memory consumed with myOdbc and VB.NET

------_=_NextPart_001_01C66FB6.ADEE80BF
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> Attached is a working example and with a schema for the table.

Much better, thank you :-).

I can confirm your findings using MyODBC 3.51.12-2.

It seems to leak ~35 bytes per query with MissingSchemaAction
set to Add and ~563 bytes using AddWithKey, none of which seems
to be a leak in managed territory.

A wild speculation could be that .NET tickles a particular MyODBC
function that leaks a 512 byte buffer...

> The program exits after 500 queries on dataadapter.fill with
> exception, "Object reference not set to an instance of an object"
> and about 1.5 GB memory is consumed!

It's not quite as bleak here, I cannot reproduce that.

Which version of MyODBC are you using?
(Note that the only useful MyODBC release number is the one that was
on the web page where you downloaded it - the version number on the
DLL is most often grossly inaccurate.)

> The application runs on more then 10 other servers without problem,
> it's just related to one server.

By "server", do you mean "MySQL client running on a server"
or "MySQL server"?

Enough questions, carrying on...

A MyODBC trace from each scenario would be good, that way we could
compare and see if any extra or different calls are made when
MissingSchemaAction is set to AddWithKey. Tracing seems to be
broken though, so we can't do that.

We can test if the number of rows has an effect on the amount
leaked. Should be straightforward.

The schema does seem to have an effect, so another thing to try
could be to remove fields from the table per a binary search algorithm,
until we know what exactly triggers this bug. With a little luck,
a particular nastyness in the schema (if any) can be found in less
than 10 tries.

Afterwards it could be helpful to try and run the test using another
database, just to be sure that it's really a MyODBC and not an ODBC
issue. Although it is much more likely to be a MyODBC issue.

When we cannot get any further, filing a bug report on
http://bugs.mysql.com is probably the next logical step.

(I have an open bug that's soon 2 years old, so if there's any
justice in the world, your issue will be fixed around 2008 ;-))

I've attached a modified version of your test case.
It's more complicated, but it can run without the user doing much
preparation. Also it can keep track of it's own memory usage.

It comes with a neat and simple...

Reproduction recipe (-:
- Setup MySQL server and database "test"
- Install MyODBC, MDAC and .NET Framework v2
- Fill in host, user, password and database in Module2.vbs
- Compile: "c:\> vbc Module2.vbs"
- Run Module2.exe

Reproduction recipe, not tickling leak:
- set 'leak' to False in Module2.vbs
- Compile
- Rerun test

Would you mind running a test with the modified version?
Just to get some actual numbers to compare with.

If it crashes early on, you'll need to decrease runs to 500
and probeMargin to 100 or so to get any useful numbers out..



------_=_NextPart_001_01C66FB6.ADEE80BF
Content-Type: text/plain; charset=us-ascii


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org
------_=_NextPart_001_01C66FB6.ADEE80BF--

RE: Huge memory consumed with myOdbc and VB.NET

------_=_NextPart_001_01C66FB7.766C44E7
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Seems like MySQL nukes attachments on their mailing lists.

Renamed to "Module2.vb.txt", hope it gets through now.


------_=_NextPart_001_01C66FB7.766C44E7
Content-Type: text/plain;
name="Module2.vb.txt"
Content-Transfer-Encoding: base64
Content-Description: Module2.vb.txt
Content-Disposition: attachment;
filename="Module2.vb.txt"

SW1wb3J0cyBTeXN0ZW0uRGF0YQ0KSW1wb3J0cyBTeXN0ZW0uRGF0YS5PZGJj DQpJbXBvcnRzIFN5
c3RlbS5EaWFnbm9zdGljcw0KDQpNb2R1bGUgTW9kdWxlMg0KCUNvbnN0IGhv c3QgQXMgU3RyaW5n
ID0gImxvY2FsaG9zdCINCglDb25zdCB1c2VyIEFzIFN0cmluZyA9ICJyb290 Ig0KCUNvbnN0IHB3
ZCBBcyBTdHJpbmcgPSAiIg0KCUNvbnN0IGRiIEFzIFN0cmluZyA9ICJ0ZXN0 Ig0KDQoJQ29uc3Qg
cm93cyBBcyBJbnRlZ2VyID0gMTAwMDAwDQoJQ29uc3QgcnVucyBBcyBJbnRl Z2VyID0gNTAwMDAN
CglDb25zdCBwcm9iZU1hcmdpbiBBcyBJbnRlZ2VyID0gMTAwMDANCglDb25z dCBsZWFrIEFzIEJv
b2xlYW4gPSBUcnVlDQoJQ29uc3QgZ2NFYWNoUnVuIEFzIEJvb2xlYW4gPSBU cnVlDQoNCglTdWIg
TWFpbigpDQoJCScgQ29ubmVjdCB0byBkYXRhYmFzZQ0KCQlEaW0gY29ubiBB cyBPZGJjQ29ubmVj
dGlvbg0KCQlEaW0gYWRhcHRlciBBcyBPZGJjRGF0YUFkYXB0ZXINCgkJRGlt IGRzIEFzIE5ldyBE
YXRhU2V0DQoJCURpbSBzIEFzIFN0cmluZw0KCQlzID0gU3RyaW5nLkZvcm1h dCgiRHJpdmVyPXt7
TXlTUUwgT0RCQyAzLjUxIERyaXZlcn19O1NlcnZlcj17MH07VWlkPXsxfTtQ d2Q9ezJ9O0RhdGFi
YXNlPXszfSIsIGhvc3QsIHVzZXIsIHB3ZCwgZGIpDQoJCWNvbm4gPSBOZXcg T2RiY0Nvbm5lY3Rp
b24ocykNCgkJY29ubi5PcGVuKCkNCgkJcyA9ICJTRUxFQ1QgKiBGUk9NIHBy aXN0ZXN0IFdIRVJF
IEFydG5yPScxJyBBTkQgRGF0dW09JzIwMDYtMDEtMDEnIg0KCQlhZGFwdGVy ID0gTmV3IE9kYmNE
YXRhQWRhcHRlcihzLCBjb25uKQ0KDQoJCScgUHJlcGFyZSB0ZXN0IHRhYmxl DQoJCUNyZWF0ZVRh
YmxlKGNvbm4pDQoJCUZpbGxUYWJsZShjb25uKQ0KDQoJCScgV2hlbiByZW1v dmluZyB0aGlzIGxp
bmUgdGhlIGlzc3VlIGRvZXNuJ3QgYXJpc2UhDQoJCUlmIGxlYWsgVGhlbg0K CQkJYWRhcHRlci5N
aXNzaW5nU2NoZW1hQWN0aW9uID0gTWlzc2luZ1NjaGVtYUFjdGlvbi5BZGRX aXRoS2V5DQoJCUVu
ZCBJZg0KDQoJCScgUHJlcGFyZSB2YXJpb3VzIG1lbW9yeSBjb3VudGVycyBl dGMuDQoJCURpbSBw
bmFtZSBBcyBTdHJpbmcNCgkJcG5hbWUgPSBQcm9jZXNzLkdldEN1cnJlbnRQ cm9jZXNzKCkuUHJv
Y2Vzc05hbWUNCgkJRGltIHBjIEFzIFBlcmZvcm1hbmNlQ291bnRlcg0KCQlw YyA9IE5ldyBQZXJm
b3JtYW5jZUNvdW50ZXIoIlByb2Nlc3MiLCAiUHJpdmF0ZSBCeXRlcyIsIHBu YW1lLCBUcnVlKQ0K
CQlEaW0gbWF4VG90YWxVc2UgQXMgSW50ZWdlciA9IDANCgkJRGltIG1heFdl VXNlIEFzIEludGVn
ZXIgPSAwDQoJCUNvbnNvbGUuV3JpdGVMaW5lKCJDb2xsZWN0aW5nIGdhcmJh Z2UgZWFjaCBpdGVy
YXRpb246IHswfSIsIGdjRWFjaFJ1bikNCgkJQ29uc29sZS5Xcml0ZUxpbmUo IlNob3VsZCBleGVy
Y2lzZSBsZWFrOiB7MH0iLCBsZWFrKQ0KDQoJCURpbSBsYXN0IEFzIERhdGVU aW1lID0gRGF0ZVRp
bWUuTm93DQoJCURpbSBpdGVyUGVyTWluIEFzIERvdWJsZQ0KCQlEaW0gcmVt YWluIEFzIFN0cmlu
ZyA9ICI/Ig0KCQlEaW0gbWVtU3RhcnQgQXMgTG9uZyA9IDANCgkJRGltIG1l bUVuZCBBcyBMb25n
ID0gMA0KCQlEaW0gY291bnQgQXMgSW50ZWdlciA9IHJ1bnMNCgkJRG8gV2hp bGUgY291bnQgPiAw
DQoJCQlJZiBjb3VudCA9IHJ1bnMgLSBwcm9iZU1hcmdpbiBUaGVuDQoJCQkJ JyBQcm9iZSBsYXRl
IGZvciBwcmVjaXNpb24NCgkJCQltZW1TdGFydCA9IHBjLlJhd1ZhbHVlDQoJ CQlFbmQgSWYNCgkJ
CUlmIGNvdW50IE1vZCAxMDAgPSAwIEFuZCBjb3VudCA8IHJ1bnMgVGhlbg0K CQkJCWl0ZXJQZXJN
aW4gPSA2MEQgLyAoKERhdGVUaW1lLk5vdyAtIGxhc3QpLlRvdGFsU2Vjb25k cyAvIDEwMEQpDQoJ
CQkJbGFzdCA9IERhdGVUaW1lLk5vdw0KCQkJCXJlbWFpbiA9ICJ+IiAmIENJ bnQoY291bnQgLyBp
dGVyUGVyTWluKSAmICIgbWlucyINCgkJCUVuZCBJZg0KDQoJCQknIExvYWQg ZGF0YQ0KCQkJVHJ5
DQoJCQkJYWRhcHRlci5GaWxsKGRzLCAicHJpc3Rlc3QiKQ0KCQkJQ2F0Y2gg ZXggQXMgTnVsbFJl
ZmVyZW5jZUV4Y2VwdGlvbg0KCQkJCUNvbnNvbGUuV3JpdGVMaW5lKHZiQ3JM ZiAmIHZiQ3JMZiAm
ICJIZXJlJ3MgdGhlIGV4Y2VwdGlvbiB3ZSB3YW50IHRvIGRlbW9uc3RyYXRl OiIgJiB2YkNyTGYg
JiB2YkNyTGYgJiAiezB9IiwgZXguVG9TdHJpbmcoKSkNCgkJCQltZW1FbmQg PSBwYy5SYXdWYWx1
ZQ0KCQkJCUV4aXQgRG8NCgkJCUVuZCBUcnkNCg0KCQkJJyBDaGVjayBmb3Ig YW5vbWFsaWVzIGlu
IG51bWJlciBvZiB0YWJsZXMgLyByb3dzDQoJCQlEaW0gdGFibGVzIEFzIElu dGVnZXIgPSAwDQoJ
CQlEaW0gcm93cyBBcyBJbnRlZ2VyID0gMA0KCQkJRGltIHQgQXMgRGF0YVRh YmxlDQoJCQlEaW0g
YW5vbWFseSBBcyBTdHJpbmcNCgkJCUZvciBFYWNoIHQgSW4gZHMuVGFibGVz DQoJCQkJdGFibGVz
ICs9IDENCgkJCQlyb3dzICs9IHQuUm93cy5Db3VudA0KCQkJTmV4dA0KCQkJ SWYgdGFibGVzICsg
cm93cyA9IDIgVGhlbg0KCQkJCWFub21hbHkgPSBTdHJpbmcuRW1wdHkNCgkJ CUVsc2UNCgkJCQlh
bm9tYWx5ID0gU3RyaW5nLkZvcm1hdCgiLCBhbm9tYWx5IC0gdGFibGVzL3Jv d3M6IHswfS97MX0i
LCB0YWJsZXMsIHJvd3MpDQoJCQlFbmQgSWYNCg0KCQkJJyBMb2FkIG1lbW9y eSBjb3VudGVycywg
b3B0aW9uYWxseSBydW4gZ2FyYmFnZSBjb2xsZWN0b3INCgkJCURpbSB3ZVVz ZSBBcyBJbnRlZ2Vy
DQoJCQlEaW0gdG90YWxVc2UgQXMgSW50ZWdlcg0KCQkJd2VVc2UgPSBDSW50 KEdDLkdldFRvdGFs
TWVtb3J5KGdjRWFjaFJ1bikgLyAxMDI0KQ0KCQkJdG90YWxVc2UgPSBDSW50 KHBjLlJhd1ZhbHVl
IC8gMTAyNCkNCgkJCUlmICh0b3RhbFVzZSA+IG1heFRvdGFsVXNlKSBPciAo d2VVc2UgPiBtYXhX
ZVVzZSkgVGhlbg0KCQkJCW1heFRvdGFsVXNlID0gdG90YWxVc2UNCgkJCQlt YXhXZVVzZSA9IHdl
VXNlDQoJCQkJQ29uc29sZS5Xcml0ZUxpbmUoKQ0KCQkJRW5kIElmDQoNCgkJ CUNvbnNvbGUuV3Jp
dGUodmJDciAmICJMb29wOiB7MH0sIHdlIHVzZTogezF9a0IsIHRvdGFsIHVz ZWQ6IHsyfWtCezN9
LCByZW1haW46IHs0fSAgICAgICAiLCBydW5zIC0gY291bnQsIHdlVXNlLCB0 b3RhbFVzZSwgYW5v
bWFseSwgcmVtYWluKQ0KDQoJCQknIENsZWFyIGxvYWRlZCBkYXRhDQoJCQlk cy5UYWJsZXMoInBy
aXN0ZXN0IikuQ2xlYXIoKQ0KCQkJY291bnQgLT0gMQ0KCQkJSWYgY291bnQg PSBwcm9iZU1hcmdp
biBUaGVuDQoJCQkJJyBQcm9iZSBlYXJseSBmb3IgcHJlY2lzaW9uDQoJCQkJ bWVtRW5kID0gcGMu
UmF3VmFsdWUNCgkJCUVuZCBJZg0KCQlMb29wDQoJCUlmIGNvdW50ID0gMCBU aGVuDQoJCQlDb25z
b2xlLldyaXRlTGluZSh2YkNyTGYgJiB2YkNyTGYgJiAiRG9uZSwgYWxsIGl0 ZXJhdGlvbnMgY29t
cGxldGVkLiIpDQoJCUVuZCBJZg0KCQlDb25zb2xlLldyaXRlTGluZSgiTWVt b3J5IGxlYWtlZCBh
ZnRlciB7MH0gaXRlcmF0aW9uczogfnsxfSBieXRlcyBwZXIgaXRlcmF0aW9u IiwgcnVucywgQ0lu
dCgobWVtRW5kIC0gbWVtU3RhcnQpIC8gKHJ1bnMgLSAyICogcHJvYmVNYXJn aW4pKSkNCgkJQ29u
c29sZS5SZWFkTGluZSgpDQoJRW5kIFN1Yg0KDQoJU3ViIENyZWF0ZVRhYmxl KGNvbm4gQXMgT2Ri
Y0Nvbm5lY3Rpb24pDQoJCUNvbnNvbGUuV3JpdGVMaW5lKCJDcmVhdGluZyB0 YWJsZS4uLiIpDQoJ
CURpbSBjbWQgQXMgT2RiY0NvbW1hbmQgPSBjb25uLkNyZWF0ZUNvbW1hbmQo KQ0KCQlEaW0gc3Fs
IEFzIFN0cmluZyA9IF8NCgkJCSJDUkVBVEUgVEFCTEUgSUYgTk9UIEVYSVNU UyBgcHJpc3Rlc3Rg
ICgiICYgXw0KCQkJIiAgYFVyc3BydW5nYCBjaGFyKDEpIE5PVCBOVUxMIGRl ZmF1bHQgJycsIiAm
IF8NCgkJCSIgIGBBcnRucmAgdmFyY2hhcigxMykgTk9UIE5VTEwgZGVmYXVs dCAnJywiICYgXw0K
CQkJIiAgYERhdHVtYCBkYXRlIE5PVCBOVUxMIGRlZmF1bHQgJzAwMDAtMDAt MDAnLCIgJiBfDQoJ
CQkiICBgQnJ1dHRvcHJpc2AgZG91YmxlKDEwLDIpIE5PVCBOVUxMIGRlZmF1 bHQgJzAuMDAnLCIg
JiBfDQoJCQkiICBgTmV0dG9wcmlzYCBkb3VibGUoMTAsMikgTk9UIE5VTEwg ZGVmYXVsdCAnMC4w
MCcsIiAmIF8NCgkJCSIgIGBUb3RhbHJhYmAgZG91YmxlKDUsMikgTk9UIE5V TEwgZGVmYXVsdCAn
MC4wMCcsIiAmIF8NCgkJCSIgIGBJbmtwcmlzYCBkb3VibGUoMTAsMikgTk9U IE5VTEwgZGVmYXVs
dCAnMC4wMCcsIiAmIF8NCgkJCSIgIGBJbmtwcmlzX2xhc3RgIHNtYWxsaW50 KDEpIE5PVCBOVUxM
IGRlZmF1bHQgJzAnLCIgJiBfDQoJCQkiICBgUmFiMWAgZG91YmxlKDUsMikg Tk9UIE5VTEwgZGVm
YXVsdCAnMC4wMCcsIiAmIF8NCgkJCSIgIGBSYWIyYCBkb3VibGUoNSwyKSBO T1QgTlVMTCBkZWZh
dWx0ICcwLjAwJywiICYgXw0KCQkJIiAgYFJhYjNgIGRvdWJsZSg1LDIpIE5P VCBOVUxMIGRlZmF1
bHQgJzAuMDAnLCIgJiBfDQoJCQkiICBgUmFiNGAgZG91YmxlKDUsMikgTk9U IE5VTEwgZGVmYXVs
dCAnMC4wMCcsIiAmIF8NCgkJCSIgIGBSYWI1YCBkb3VibGUoNSwyKSBOT1Qg TlVMTCBkZWZhdWx0
ICcwLjAwJywiICYgXw0KCQkJIiAgYFJhYmdycDFgIHZhcmNoYXIoOCkgTk9U IE5VTEwgZGVmYXVs
dCAnJywiICYgXw0KCQkJIiAgYFJhYmdycDJgIHZhcmNoYXIoOCkgTk9UIE5V TEwgZGVmYXVsdCAn
JywiICYgXw0KCQkJIiAgYFJhYmdycDNgIHZhcmNoYXIoOCkgTk9UIE5VTEwg ZGVmYXVsdCAnJywi
ICYgXw0KCQkJIiAgYFJhYmdycDRgIHZhcmNoYXIoOCkgTk9UIE5VTEwgZGVm YXVsdCAnJywiICYg
Xw0KCQkJIiAgYFJhYmdycDVgIHZhcmNoYXIoOCkgTk9UIE5VTEwgZGVmYXVs dCAnJywiICYgXw0K
CQkJIiAgYEtvc3RwcmlzYCBkb3VibGUoMTAsMikgTk9UIE5VTEwgZGVmYXVs dCAnMC4wMCcsIiAm
IF8NCgkJCSIgIGBLb3N0cHJpc19sYXN0YCBzbWFsbGludCgxKSBOT1QgTlVM TCBkZWZhdWx0ICcw
JywiICYgXw0KCQkJIiAgYEZyYWt0cHJvY2AgZG91YmxlKDUsMikgTk9UIE5V TEwgZGVmYXVsdCAn
MC4wMCcsIiAmIF8NCgkJCSIgIGBGcmFrdHByb2NfbGFzdGAgc21hbGxpbnQo MSkgTk9UIE5VTEwg
ZGVmYXVsdCAnMCcsIiAmIF8NCgkJCSIgIGBGcmFrdHByaXNgIGRvdWJsZSgx MCwyKSBOT1QgTlVM
TCBkZWZhdWx0ICcwLjAwJywiICYgXw0KCQkJIiAgYEZyYWt0cHJpc19sYXN0 YCBzbWFsbGludCgx
KSBOT1QgTlVMTCBkZWZhdWx0ICcwJywiICYgXw0KCQkJIiAgYEZyYWt0a29k YCBjaGFyKDEpIE5P
VCBOVUxMIGRlZmF1bHQgJzAnLCIgJiBfDQoJCQkiICBgUHJpc2dydXBwYCBj aGFyKDMpIE5PVCBO
VUxMIGRlZmF1bHQgJycsIiAmIF8NCgkJCSIgIGBDYXByaXNgIGRvdWJsZSgx MCwyKSBOT1QgTlVM
TCBkZWZhdWx0ICcwLjAwJywiICYgXw0KCQkJIiAgYE1hcmdpbmFsYCBkb3Vi bGUoNSwyKSBOT1Qg
TlVMTCBkZWZhdWx0ICcwLjAwJywiICYgXw0KCQkJIiAgYFRnYCBkb3VibGUo NSwyKSBOT1QgTlVM
TCBkZWZhdWx0ICcwLjAwJywiICYgXw0KCQkJIiAgYFRnX2xhc3RgIHNtYWxs aW50KDEpIE5PVCBO
VUxMIGRlZmF1bHQgJzAnLCIgJiBfDQoJCQkiICBgQXZydW5kbmluZ2AgZG91 YmxlKDYsMikgTk9U
IE5VTEwgZGVmYXVsdCAnMC4wMCcsIiAmIF8NCgkJCSIgIGBGb3JzcHJpc2Ag ZG91YmxlKDEwLDIp
IE5PVCBOVUxMIGRlZmF1bHQgJzAuMDAnLCIgJiBfDQoJCQkiICBgRm9yc3By aXNfbGFzdGAgc21h
bGxpbnQoMSkgTk9UIE5VTEwgZGVmYXVsdCAnMCcsIiAmIF8NCgkJCSIgIGBG b3JzcHJpc19lZ2V0
YCBkb3VibGUoMTAsMikgTk9UIE5VTEwgZGVmYXVsdCAnMC4wMCcsIiAmIF8N CgkJCSIgIGBBa3R1
ZWxsdF9wcmlzYCBjaGFyKDEpIE5PVCBOVUxMIGRlZmF1bHQgJzAnLCIgJiBf DQoJCQkiICBgUmFi
Z3JwX2xhc3RgIHNtYWxsaW50KDEpIE5PVCBOVUxMIGRlZmF1bHQgJzAnLCIg JiBfDQoJCQkiICBg
dHNgIHRpbWVzdGFtcCgxNCkgTk9UIE5VTEwsIiAmIF8NCgkJCSIgIGBGcmFr dFR5cGAgdGlueWlu
dCgzKSB1bnNpZ25lZCBOT1QgTlVMTCBkZWZhdWx0ICcwJywiICYgXw0KCQkJ IiAgYE5ldHRvUmFi
Z3JwYCB2YXJjaGFyKDgpIE5PVCBOVUxMIGRlZmF1bHQgJycsIiAmIF8NCgkJ CSIgIGBOZXR0b1Jh
YmAgZG91YmxlKDUsMikgTk9UIE5VTEwgZGVmYXVsdCAnMC4wMCcsIiAmIF8N CgkJCSIgIGBOZXR0
b1JhYmdycF9MYXN0YCB0aW55aW50KDEpIE5PVCBOVUxMIGRlZmF1bHQgJzAn LCIgJiBfDQoJCQki
ICBgRnJha3Rrb2RfbGFzdGAgdGlueWludCgxKSBOT1QgTlVMTCBkZWZhdWx0 ICcwJywiICYgXw0K
CQkJIiAgYEFsdHByaXMxYCBkb3VibGUoMTAsMikgTk9UIE5VTEwgZGVmYXVs dCAnMC4wMCcsIiAm
IF8NCgkJCSIgIGBBbHRwcmlzMmAgZG91YmxlKDEwLDIpIE5PVCBOVUxMIGRl ZmF1bHQgJzAuMDAn
LCIgJiBfDQoJCQkiICBgQWx0cHJpczNgIGRvdWJsZSgxMCwyKSBOT1QgTlVM TCBkZWZhdWx0ICcw
LjAwJywiICYgXw0KCQkJIiAgUFJJTUFSWSBLRVkgIChgQXJ0bnJgLGBEYXR1 bWApIiAmIF8NCgkJ
CSIpIFRZUEU9TXlJU0FNIg0KCQljbWQuQ29tbWFuZFRleHQgPSBzcWwNCgkJ Y21kLkV4ZWN1dGVO
b25RdWVyeSgpDQoJRW5kIFN1Yg0KDQoJU3ViIEZpbGxUYWJsZShjb25uIEFz IE9kYmNDb25uZWN0
aW9uKQ0KCQlDb25zb2xlLldyaXRlTGluZSgiQ3JlYXRpbmcgdGVzdCBkYXRh Li4uIikNCgkJRGlt
IGNtZCBBcyBPZGJjQ29tbWFuZCA9IGNvbm4uQ3JlYXRlQ29tbWFuZCgpDQoJ CURpbSBzcWwgQXMg
U3RyaW5nDQoJCUNvbnN0IGluc2VydFNxbCBBcyBTdHJpbmcgPSBfDQoJCQki SU5TRVJUIElOVE8g
cHJpc3Rlc3QgVkFMVUVTICgiICYgXw0KCQkJIid7MH0nLCAnezF9JywgJ3sy fScsICd7M30nLCAn
ezR9JywgJ3s1fScsICd7Nn0nLCAnezd9JywgJ3s4fScsICd7OX0nLCAiICYg Xw0KCQkJIid7MTB9
JywgJ3sxMX0nLCAnezEyfScsICd7MTN9JywgJ3sxNH0nLCAnezE1fScsICd7 MTZ9JywgJ3sxN30n
LCAnezE4fScsICd7MTl9JywgIiAmIF8NCgkJCSInezIwfScsICd7MjF9Jywg J3syMn0nLCAnezIz
fScsICd7MjR9JywgJ3syNX0nLCAnezI2fScsICd7Mjd9JywgJ3syOH0nLCAn ezI5fScsICIgJiBf
DQoJCQkiJ3szMH0nLCAnezMxfScsICd7MzJ9JywgJ3szM30nLCAnezM0fScs ICd7MzV9JywgJ3sz
Nn0nLCAnezM3fScsICd7Mzh9JywgJ3szOX0nLCAiICYgXw0KCQkJIid7NDB9 JywgJ3s0MX0nLCAn
ezQyfScsICd7NDN9JywgJ3s0NH0nKSINCg0KCQlzcWwgPSAiU0VMRUNUIENP VU5UKCopIEZST00g
cHJpc3Rlc3QiDQoJCWNtZC5Db21tYW5kVGV4dCA9IHNxbA0KCQlEaW0gY250 IEFzIEludGVnZXIg
PSBDSW50KGNtZC5FeGVjdXRlU2NhbGFyKCkpDQoNCgkJSWYgY250IDw+IFJv d3MgVGhlbg0KCQkJ
c3FsID0gIlRSVU5DQVRFIFRBQkxFIHByaXN0ZXN0Ig0KCQkJY21kLkNvbW1h bmRUZXh0ID0gc3Fs
DQoJCQljbWQuRXhlY3V0ZU5vblF1ZXJ5KCkNCg0KCQkJRGltIEkgQXMgSW50 ZWdlcg0KCQkJRm9y
IEkgPSAxIFRvIFJvd3MNCgkJCQlDb25zb2xlLldyaXRlKHZiQ3IgJiBJICYg Ii4uLiIpDQoJCQkJ
RGltIGIgQXMgQnl0ZSA9IEkgTW9kIDEwDQoJCQkJRGltIGMgQXMgQ2hhciA9 IENocig2NSArIEkg
TW9kIDI2KQ0KCQkJCURpbSBkIEFzIFN0cmluZyA9ICIyMDA2LTAxLTAxIg0K CQkJCURpbSBkdCBB
cyBTdHJpbmcgPSBEYXRlVGltZS5Ob3cuVG9TdHJpbmcoInl5eXktTU0tZGQg SEg6bW06c3MiKQ0K
CQkJCURpbSBmIEFzIEludGVnZXIgPSBJIE1vZCAxMDAwDQoJCQkJRGltIHMg QXMgU3RyaW5nID0g
SS5Ub1N0cmluZygpDQoJCQkJc3FsID0gU3RyaW5nLkZvcm1hdChpbnNlcnRT cWwsIF8NCgkJCQkJ
YywgcywgZCwgSSwgSSwgZiwgSSwgYiwgZiwgZiwgZiwgZiwgZiwgcywgcywg cywgcywgcywgSSwg
YiwgZiwgYiwgXw0KCQkJCQlJLCBiLCBjLCBjLCBJLCBmLCBmLCBiLCBmLCBJ LCBiLCBJLCBjLCBi
LCBkdCwgYiwgcywgZiwgYiwgYiwgSSwgSSwgSSkNCgkJCQljbWQuQ29tbWFu ZFRleHQgPSBzcWwN
CgkJCQljbWQuRXhlY3V0ZU5vblF1ZXJ5KCkNCgkJCU5leHQNCgkJCUNvbnNv bGUuV3JpdGVMaW5l
KCJEb25lLiAgICAgICAgIikNCgkJRWxzZQ0KCQkJQ29uc29sZS5Xcml0ZUxp bmUoIlNraXBwZWQu
IikNCgkJRW5kIElmDQoJRW5kIFN1Yg0KRW5kIE1vZHVsZQ0K


------_=_NextPart_001_01C66FB7.766C44E7
Content-Type: text/plain; charset=us-ascii


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org
------_=_NextPart_001_01C66FB7.766C44E7--

RE: Huge memory consumed with myOdbc and VB.NET

David, thanks for your effort and suggestions on this issue, I will come
back to you as soon I can (later on next week) after some more tests!
The netV2 suggestions complicates the testing, but I'll give it a try!

And som answers to your questions..
>Which version of MyODBC are you using?
The version I have used is Myodbc 3.51.12-win32).

>By "server", do you mean "MySQL client running on a server"
or "MySQL server"?
We have about 10 installed MySQL servers (windows servers) and each
installation is from 1 to 30 clients using myODBC and 5 of these
installations is running Windows terminal server , the rest is ordinary
XP/2000 PC.
All installation is on customers own servers.



--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=3Dgcdmo-myodbc@m.gmane.o rg

RE: Huge memory consumed with myOdbc and VB.NET

I've some new information about the issue and it's seems to be related
to Windows 2003 servicepack 1.
An ugly workaround for the issue was to install an older version of
myOdbc(3.51.6).
The performance is also quite bad for some reason.
Further more MySQL support has been able to reproduce the problem.



--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=3Dgcdmo-myodbc@m.gmane.o rg

RE: Huge memory consumed with myOdbc and VB.NET

Patrik Lindvall wrote:
> The program exits after 500 queries on dataadapter.fill with
> exception, "Object reference not set to an instance of an object"
> and about 1.5 GB memory is consumed!

I might've managed to reproduce it,
I now see 16910 bytes leaked per query.

It's a problem that comes and goes though,
I haven't accurately pin-pointed it..

> I've some new information about the issue and it
> seems to be related to Windows 2003 servicepack 1.

Any details?


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=3Dgcdmo-myodbc@m.gmane.o rg

RE: Huge memory consumed with myOdbc and VB.NET

I let you know when further information is available.


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=3Dgcdmo-myodbc@m.gmane.o rg