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) 17 2353
"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));
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)
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)
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> writesThe 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" <al*********@nospam.thanx.invalid> wrote in message
news:9+**************@nospamthankyou.spam... ...and all will be fine?
Yep.
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> writesThe 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" <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...
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> writesYes, 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)
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> writesYes, 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)
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)
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)
"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...
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)
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?
"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...
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)
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) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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...
|
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...
...
|
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...
|
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...
|
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...
|
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...
|
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;" +...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
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...
|
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...
|
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...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
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...
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |