473,289 Members | 1,848 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,289 software developers and data experts.

Do I need to close a connection after grabbing a datareader?

Hello,

I have a generic method in a utility class that grabs an sqldatareader
and returns it. Due to the fact that (AFAIK), you can't close the
database connection before you've read the data, this method doesn't
close it, it just returns the datareader. The calling code uses the
datareader and then just lets it drop out of scope, to be picked up by
the garbage collector.

Is this a problem? A friend of mine suggested to me that not explicitly
closing the connection will leave it open, resulting in the connection
pool being emptied. I've not seen any problems on the server, but that
doesn't prove anything. I previously assumed that the connection would
be closed when the connection object was destroyed. Is this right?

Anyone care to comment? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)
Feb 8 '06 #1
17 2352
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
I previously assumed that the connection would be closed when the
connection object was destroyed. Is this right?
Not necessarily...
Anyone care to comment? TIA


You say your method returns a DataReader object to its caller...therefore,
just do the following, and the connection gets closed automatically for you.

return (<MyCommandObject>.ExecuteReader(CommandBehavior.C loseConnection));
Feb 8 '06 #2
The caller would then be responsible for closing the data reader. If the
datareader was created by calling
ExecuteReader(CommandBehavior.CloseConnection), then closing the data reader
will close the underlying connection. If this is not how the datareader was
created, then closing the data reader will not close the connection and you
will wind up with a connection leak.

The way you are doing it right now will end up in a connection leak under
load, your friend is correct.

The connection will be closed when the object is destroyed - the problem is,
you don't know what that will be. Going out of scope is not the same as
being garbage collected. The GC will run when it needs to reclaim some
memory, not as soon as a variable goes out of scope - but you are likely to
run out of connections in the pool far before then.

"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
Hello,

I have a generic method in a utility class that grabs an sqldatareader and
returns it. Due to the fact that (AFAIK), you can't close the database
connection before you've read the data, this method doesn't close it, it
just returns the datareader. The calling code uses the datareader and then
just lets it drop out of scope, to be picked up by the garbage collector.

Is this a problem? A friend of mine suggested to me that not explicitly
closing the connection will leave it open, resulting in the connection
pool being emptied. I've not seen any problems on the server, but that
doesn't prove anything. I previously assumed that the connection would be
closed when the connection object was destroyed. Is this right?

Anyone care to comment? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)

Feb 8 '06 #3
Thanks to both of you for the replies.

So, am I correct in thinking that if the utility method creates a
command object (cmdCommand), and then does something like...

SqlDataReader dtrData = cmdCommand.ExecuteReader(CommandBehavior.CloseConn ection);
return dtrData;

then the calling code just needs to do...

SqlDataReader myData = utilmethod(...);
// do the stuff with the datareader
myData.Close();

....and all will be fine? Please check I've got this right.

Thanks again

In article <eC**************@TK2MSFTNGP09.phx.gbl>, "Marina Levit
[MVP]" <so*****@nospam.com> writes
The caller would then be responsible for closing the data reader. If the
datareader was created by calling
ExecuteReader(CommandBehavior.CloseConnection), then closing the data reader
will close the underlying connection. If this is not how the datareader was
created, then closing the data reader will not close the connection and you
will wind up with a connection leak.

The way you are doing it right now will end up in a connection leak under
load, your friend is correct.

The connection will be closed when the object is destroyed - the problem is,
you don't know what that will be. Going out of scope is not the same as
being garbage collected. The GC will run when it needs to reclaim some
memory, not as soon as a variable goes out of scope - but you are likely to
run out of connections in the pool far before then.

"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
Hello,

I have a generic method in a utility class that grabs an sqldatareader and
returns it. Due to the fact that (AFAIK), you can't close the database
connection before you've read the data, this method doesn't close it, it
just returns the datareader. The calling code uses the datareader and then
just lets it drop out of scope, to be picked up by the garbage collector.

Is this a problem? A friend of mine suggested to me that not explicitly
closing the connection will leave it open, resulting in the connection
pool being emptied. I've not seen any problems on the server, but that
doesn't prove anything. I previously assumed that the connection would be
closed when the connection object was destroyed. Is this right?

Anyone care to comment? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)



--
Alan Silver
(anything added below this line is nothing to do with me)
Feb 8 '06 #4
Yes, that looks about right.

To avoid any potential problems like this you can just return only
datatables from your helper methods. That way whatever code is using the
result set doesn't have to worry about closing the connection.

"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:9+**************@nospamthankyou.spam...
Thanks to both of you for the replies.

So, am I correct in thinking that if the utility method creates a command
object (cmdCommand), and then does something like...

SqlDataReader dtrData =
cmdCommand.ExecuteReader(CommandBehavior.CloseConn ection);
return dtrData;

then the calling code just needs to do...

SqlDataReader myData = utilmethod(...);
// do the stuff with the datareader
myData.Close();

...and all will be fine? Please check I've got this right.

Thanks again

In article <eC**************@TK2MSFTNGP09.phx.gbl>, "Marina Levit
[MVP]" <so*****@nospam.com> writes
The caller would then be responsible for closing the data reader. If the
datareader was created by calling
ExecuteReader(CommandBehavior.CloseConnection) , then closing the data
reader
will close the underlying connection. If this is not how the datareader
was
created, then closing the data reader will not close the connection and
you
will wind up with a connection leak.

The way you are doing it right now will end up in a connection leak under
load, your friend is correct.

The connection will be closed when the object is destroyed - the problem
is,
you don't know what that will be. Going out of scope is not the same as
being garbage collected. The GC will run when it needs to reclaim some
memory, not as soon as a variable goes out of scope - but you are likely
to
run out of connections in the pool far before then.

"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
Hello,

I have a generic method in a utility class that grabs an sqldatareader
and
returns it. Due to the fact that (AFAIK), you can't close the database
connection before you've read the data, this method doesn't close it, it
just returns the datareader. The calling code uses the datareader and
then
just lets it drop out of scope, to be picked up by the garbage
collector.

Is this a problem? A friend of mine suggested to me that not explicitly
closing the connection will leave it open, resulting in the connection
pool being emptied. I've not seen any problems on the server, but that
doesn't prove anything. I previously assumed that the connection would
be
closed when the connection object was destroyed. Is this right?

Anyone care to comment? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)



--
Alan Silver
(anything added below this line is nothing to do with me)

Feb 8 '06 #5
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:9+**************@nospamthankyou.spam...
...and all will be fine?


Yep.
Feb 8 '06 #6
In article <uf**************@TK2MSFTNGP11.phx.gbl>, "Marina Levit [MVP]"
<so*****@nospam.com> writes
Yes, that looks about right.
Thanks
To avoid any potential problems like this you can just return only
datatables from your helper methods. That way whatever code is using the
result set doesn't have to worry about closing the connection.
I started using datareaders as I was told (when I first started reading
here) that they were faster and more efficient when you just wanted
forward-only data, say for binding to a repeater. Is this wrong?

Thanks again
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:9+**************@nospamthankyou.spam...
Thanks to both of you for the replies.

So, am I correct in thinking that if the utility method creates a command
object (cmdCommand), and then does something like...

SqlDataReader dtrData =
cmdCommand.ExecuteReader(CommandBehavior.CloseConn ection);
return dtrData;

then the calling code just needs to do...

SqlDataReader myData = utilmethod(...);
// do the stuff with the datareader
myData.Close();

...and all will be fine? Please check I've got this right.

Thanks again

In article <eC**************@TK2MSFTNGP09.phx.gbl>, "Marina Levit
[MVP]" <so*****@nospam.com> writes
The caller would then be responsible for closing the data reader. If the
datareader was created by calling
ExecuteReader(CommandBehavior.CloseConnection ), then closing the data
reader
will close the underlying connection. If this is not how the datareader
was
created, then closing the data reader will not close the connection and
you
will wind up with a connection leak.

The way you are doing it right now will end up in a connection leak under
load, your friend is correct.

The connection will be closed when the object is destroyed - the problem
is,
you don't know what that will be. Going out of scope is not the same as
being garbage collected. The GC will run when it needs to reclaim some
memory, not as soon as a variable goes out of scope - but you are likely
to
run out of connections in the pool far before then.

"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
Hello,

I have a generic method in a utility class that grabs an sqldatareader
and
returns it. Due to the fact that (AFAIK), you can't close the database
connection before you've read the data, this method doesn't close it, it
just returns the datareader. The calling code uses the datareader and
then
just lets it drop out of scope, to be picked up by the garbage
collector.

Is this a problem? A friend of mine suggested to me that not explicitly
closing the connection will leave it open, resulting in the connection
pool being emptied. I've not seen any problems on the server, but that
doesn't prove anything. I previously assumed that the connection would
be
closed when the connection object was destroyed. Is this right?

Anyone care to comment? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)


--
Alan Silver
(anything added below this line is nothing to do with me)



--
Alan Silver
(anything added below this line is nothing to do with me)
Feb 8 '06 #7
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:Rt**************@nospamthankyou.spam...
I started using datareaders as I was told (when I first started reading
here) that they were faster and more efficient when you just wanted
forward-only data, say for binding to a repeater. Is this wrong?


Generally speaking, that's absolutely right.

Of course there will always be someone who can prove that, under a very
particular set of circumstances, they're not as fast as one of the other
ADO.NET objects...
Feb 8 '06 #8
They might be slightly faster - but unless your application needs every
nanosecond of performance it can get, your users won't notice a difference.

Sometimes code clarity and maintanability outweighs slight performance
benefits. It might be worth it to not use datareaders if it means you won't
have to spend hours looking for the one place in the code where a developer
forgot to close the datareader that is now causing a connection leak.

I'm not saying you shouldn't use datareader, just suggesting that there are
potential coding pitfalls that go along with them.

"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:Rt**************@nospamthankyou.spam...
In article <uf**************@TK2MSFTNGP11.phx.gbl>, "Marina Levit [MVP]"
<so*****@nospam.com> writes
Yes, that looks about right.


Thanks
To avoid any potential problems like this you can just return only
datatables from your helper methods. That way whatever code is using the
result set doesn't have to worry about closing the connection.


I started using datareaders as I was told (when I first started reading
here) that they were faster and more efficient when you just wanted
forward-only data, say for binding to a repeater. Is this wrong?

Thanks again
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:9+**************@nospamthankyou.spam...
Thanks to both of you for the replies.

So, am I correct in thinking that if the utility method creates a
command
object (cmdCommand), and then does something like...

SqlDataReader dtrData =
cmdCommand.ExecuteReader(CommandBehavior.CloseConn ection);
return dtrData;

then the calling code just needs to do...

SqlDataReader myData = utilmethod(...);
// do the stuff with the datareader
myData.Close();

...and all will be fine? Please check I've got this right.

Thanks again

In article <eC**************@TK2MSFTNGP09.phx.gbl>, "Marina Levit
[MVP]" <so*****@nospam.com> writes
The caller would then be responsible for closing the data reader. If
the
datareader was created by calling
ExecuteReader(CommandBehavior.CloseConnection) , then closing the data
reader
will close the underlying connection. If this is not how the datareader
was
created, then closing the data reader will not close the connection and
you
will wind up with a connection leak.

The way you are doing it right now will end up in a connection leak
under
load, your friend is correct.

The connection will be closed when the object is destroyed - the problem
is,
you don't know what that will be. Going out of scope is not the same as
being garbage collected. The GC will run when it needs to reclaim some
memory, not as soon as a variable goes out of scope - but you are likely
to
run out of connections in the pool far before then.

"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
> Hello,
>
> I have a generic method in a utility class that grabs an sqldatareader
> and
> returns it. Due to the fact that (AFAIK), you can't close the database
> connection before you've read the data, this method doesn't close it,
> it
> just returns the datareader. The calling code uses the datareader and
> then
> just lets it drop out of scope, to be picked up by the garbage
> collector.
>
> Is this a problem? A friend of mine suggested to me that not
> explicitly
> closing the connection will leave it open, resulting in the connection
> pool being emptied. I've not seen any problems on the server, but that
> doesn't prove anything. I previously assumed that the connection would
> be
> closed when the connection object was destroyed. Is this right?
>
> Anyone care to comment? TIA
>
> --
> Alan Silver
> (anything added below this line is nothing to do with me)

--
Alan Silver
(anything added below this line is nothing to do with me)



--
Alan Silver
(anything added below this line is nothing to do with me)

Feb 8 '06 #9
OK, thanks to both of you (again)

In article <#Z**************@TK2MSFTNGP14.phx.gbl>, "Marina Levit [MVP]"
<so*****@nospam.com> writes
They might be slightly faster - but unless your application needs every
nanosecond of performance it can get, your users won't notice a difference.

Sometimes code clarity and maintanability outweighs slight performance
benefits. It might be worth it to not use datareaders if it means you won't
have to spend hours looking for the one place in the code where a developer
forgot to close the datareader that is now causing a connection leak.

I'm not saying you shouldn't use datareader, just suggesting that there are
potential coding pitfalls that go along with them.

"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:Rt**************@nospamthankyou.spam...
In article <uf**************@TK2MSFTNGP11.phx.gbl>, "Marina Levit [MVP]"
<so*****@nospam.com> writes
Yes, that looks about right.


Thanks
To avoid any potential problems like this you can just return only
datatables from your helper methods. That way whatever code is using the
result set doesn't have to worry about closing the connection.


I started using datareaders as I was told (when I first started reading
here) that they were faster and more efficient when you just wanted
forward-only data, say for binding to a repeater. Is this wrong?

Thanks again
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:9+**************@nospamthankyou.spam...
Thanks to both of you for the replies.

So, am I correct in thinking that if the utility method creates a
command
object (cmdCommand), and then does something like...

SqlDataReader dtrData =
cmdCommand.ExecuteReader(CommandBehavior.CloseConn ection);
return dtrData;

then the calling code just needs to do...

SqlDataReader myData = utilmethod(...);
// do the stuff with the datareader
myData.Close();

...and all will be fine? Please check I've got this right.

Thanks again

In article <eC**************@TK2MSFTNGP09.phx.gbl>, "Marina Levit
[MVP]" <so*****@nospam.com> writes
>The caller would then be responsible for closing the data reader. If
>the
>datareader was created by calling
>ExecuteReader(CommandBehavior.CloseConnection ), then closing the data
>reader
>will close the underlying connection. If this is not how the datareader
>was
>created, then closing the data reader will not close the connection and
>you
>will wind up with a connection leak.
>
>The way you are doing it right now will end up in a connection leak
>under
>load, your friend is correct.
>
>The connection will be closed when the object is destroyed - the problem
>is,
>you don't know what that will be. Going out of scope is not the same as
>being garbage collected. The GC will run when it needs to reclaim some
>memory, not as soon as a variable goes out of scope - but you are likely
>to
>run out of connections in the pool far before then.
>
>"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
>news:yo**************@nospamthankyou.spam.. .
>> Hello,
>>
>> I have a generic method in a utility class that grabs an sqldatareader
>> and
>> returns it. Due to the fact that (AFAIK), you can't close the database
>> connection before you've read the data, this method doesn't close it,
>> it
>> just returns the datareader. The calling code uses the datareader and
>> then
>> just lets it drop out of scope, to be picked up by the garbage
>> collector.
>>
>> Is this a problem? A friend of mine suggested to me that not
>> explicitly
>> closing the connection will leave it open, resulting in the connection
>> pool being emptied. I've not seen any problems on the server, but that
>> doesn't prove anything. I previously assumed that the connection would
>> be
>> closed when the connection object was destroyed. Is this right?
>>
>> Anyone care to comment? TIA
>>
>> --
>> Alan Silver
>> (anything added below this line is nothing to do with me)
>
>

--
Alan Silver
(anything added below this line is nothing to do with me)


--
Alan Silver
(anything added below this line is nothing to do with me)



--
Alan Silver
(anything added below this line is nothing to do with me)
Feb 8 '06 #10

My code usually looks like this

IDataReader idr = null;

try
{
idr = SomeMethodToGetAReader();

while (idr.Read())
{
//do stuff
}
finally
{
if (null!=idr)
{
idr.Close();
}
}

If you premature exit the while loop, then use the .Cancel method.

You should write more try/finally blocks, then try/catch or
try/catch/finally blocks. Google "Brad Abrams" and "finally" to find some
info on that.

This is unnecessarily expensive

try{
//try something
}
catch(Exception ex)
{throw ex;}
finally
{
}

the catch/throw isn't doing any good.


"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
Hello,

I have a generic method in a utility class that grabs an sqldatareader
and returns it. Due to the fact that (AFAIK), you can't close the
database connection before you've read the data, this method doesn't
close it, it just returns the datareader. The calling code uses the
datareader and then just lets it drop out of scope, to be picked up by
the garbage collector.

Is this a problem? A friend of mine suggested to me that not explicitly
closing the connection will leave it open, resulting in the connection
pool being emptied. I've not seen any problems on the server, but that
doesn't prove anything. I previously assumed that the connection would
be closed when the connection object was destroyed. Is this right?

Anyone care to comment? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)

Feb 10 '06 #11
In article <OE**************@TK2MSFTNGP14.phx.gbl>, sloan
<sl***@ipass.net> writes

My code usually looks like this

IDataReader idr = null;
Why do you use IDataReader, instead of (say) SqlDataReader? What's the
benefit?

Thank for the other comments.
try
{
idr = SomeMethodToGetAReader();

while (idr.Read())
{
//do stuff
}
finally
{
if (null!=idr)
{
idr.Close();
}
}

If you premature exit the while loop, then use the .Cancel method.

You should write more try/finally blocks, then try/catch or
try/catch/finally blocks. Google "Brad Abrams" and "finally" to find some
info on that.

This is unnecessarily expensive

try{
//try something
}
catch(Exception ex)
{throw ex;}
finally
{
}

the catch/throw isn't doing any good.


"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
Hello,

I have a generic method in a utility class that grabs an sqldatareader
and returns it. Due to the fact that (AFAIK), you can't close the
database connection before you've read the data, this method doesn't
close it, it just returns the datareader. The calling code uses the
datareader and then just lets it drop out of scope, to be picked up by
the garbage collector.

Is this a problem? A friend of mine suggested to me that not explicitly
closing the connection will leave it open, resulting in the connection
pool being emptied. I've not seen any problems on the server, but that
doesn't prove anything. I previously assumed that the connection would
be closed when the connection object was destroyed. Is this right?

Anyone care to comment? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)



--
Alan Silver
(anything added below this line is nothing to do with me)
Feb 13 '06 #12
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:hh**************@nospamthankyou.spam...
Why do you use IDataReader, instead of (say) SqlDataReader? What's the
benefit?


I imagine it's part of a generic DAL which will work with any RDBMS, not
just SQL Server...

I did something similar on a contract last year where the client was
designed to work with a variety of back-end RBDMS e.g. SQL, Sybase, Oracle,
FoxPro, Access, MySQL. Not *too* much of a problem once we'd made the schema
generic enough...
Feb 13 '06 #13
In article <#e**************@TK2MSFTNGP15.phx.gbl>, Mark Rae
<ma**@markN-O-S-P-A-M.co.uk> writes
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:hh**************@nospamthankyou.spam...
Why do you use IDataReader, instead of (say) SqlDataReader? What's the
benefit?


I imagine it's part of a generic DAL which will work with any RDBMS, not
just SQL Server...

I did something similar on a contract last year where the client was
designed to work with a variety of back-end RBDMS e.g. SQL, Sybase, Oracle,
FoxPro, Access, MySQL. Not *too* much of a problem once we'd made the schema
generic enough...


OK, thanks for the clarification. As I work exclusively with SQL Server,
I guess I'm safe using SqlDataReader for now.

TA ra

--
Alan Silver
(anything added below this line is nothing to do with me)
Feb 13 '06 #14
FxCop, notably, prefers IDataReader to SqlDataReader if you aren't
using any methods specific to SqlDataReader. If there isn't any
additional cost to using the interface over a concrete class, I'd be
inclined to agree - why make the code less flexible?

Feb 13 '06 #15
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:bj**************@nospamthankyou.spam...
OK, thanks for the clarification.


Nothing more than an educated guess on my part - no clarification
whatsoever...
Feb 13 '06 #16
In article <#q*************@TK2MSFTNGP14.phx.gbl>, Mark Rae
<ma**@markN-O-S-P-A-M.co.uk> writes
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:bj**************@nospamthankyou.spam...
OK, thanks for the clarification.


Nothing more than an educated guess on my part - no clarification
whatsoever...


An educated guess is still clarification to the uneducated ;-)

--
Alan Silver
(anything added below this line is nothing to do with me)
Feb 13 '06 #17
In article <11*********************@g14g2000cwa.googlegroups. com>,
Flinky Wisty Pomm <Pa********@gmail.com> writes
FxCop, notably, prefers IDataReader to SqlDataReader if you aren't
using any methods specific to SqlDataReader. If there isn't any
additional cost to using the interface over a concrete class, I'd be
inclined to agree - why make the code less flexible?


Good point, hadn't thought of it that way. Thanks.

--
Alan Silver
(anything added below this line is nothing to do with me)
Feb 13 '06 #18

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: sam | last post by:
Hello group, I have a function which is used to initiate sqlDataReader object. I was trying to invoke the close method on the DataReader object but cant really do that as the function returns a...
3
by: Craig | last post by:
I have some methods that open a database connection, get some data and then return a datareader. How do I manage closing the connection to the database then? public OracleDataReader...
4
by: Lerp | last post by:
Hi, I have this sub in which I am trying to get a client name from a second table based on a clientid value in my datalist. I am having problems grabbing the clientid value out of my datalist...
5
by: Joel Reinford | last post by:
I am attempting to verify whether a datareader is closed by calling the databind on a control. for example (fake code) Dim rdr as SqlDataReader rdr = mycommand.executeReader... ...
7
by: Joe | last post by:
Hi, Iā€™m new to asp.net. I want to create an asp.net page that allows user to edit the data. I have pasted my code below. I am able to display the data in a datagrid. At the bottom of the page...
2
by: Maziar Aflatoun | last post by:
Hi, To update the database I first open a connection, update and then I close it. Is there way to do this without opening the connection first? Such as using the DataAdaptor (which manages the...
5
by: jjmraz | last post by:
Hi, I have a situation where in a dll a SqlDataReader is created on a function call but is never closed. The datareader gets passed back to the asp.net page calling it. How should I close the...
9
by: Blarneystone | last post by:
Hi, I am using VB.NET and trying to pull data from two different tables in the database. I am using what I think is standard code. But the data I am pulling is like the following: Table1...
1
by: jinxy | last post by:
Hello, this is my code in visual c#: namespace im_client { public partial class Form2 : Form { MySqlConnection conDatabase = new MySqlConnection("Data Source=86.123.220.28;" +...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: marcoviolo | last post by:
Dear all, I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.