delete vs []delete

Hi all,
I have some strange behavior in some code
and I did see that I had delete when  I
should have []delete;

Now I am not questioning the
validity of []delete for an array of items
as opposed to delete for a singularity.

My question what kind of behavior would you expect
if you mismatch new / delete as I described.

Colin.
0
Colin
2/5/2009 1:23:50 PM
embarcadero.cppbuilder.cpp 2803 articles. 0 followers. Follow

22 Replies
1066 Views

Similar Articles

[PageSpeed] 4

On Thu, 5 Feb 2009 05:23:50 -0800
Colin Maharaj <noreply@nohost.com> wrote:

> My question what kind of behavior would you expect
> if you mismatch new / delete as I described.

I wouldn't expect /anything/, it's undefined.

-- 
Elizabeth Albin 

Please read if you have any floating point issues
http://docs.sun.com/source/806-3568/ncg_goldberg.html

Please post appropriately
http://support.codegear.forums/directory
http://support.codegear.forums/guidelines
http://support.codegear.forums/etiquette
0
Elizabeth
2/5/2009 2:01:58 PM
Hello,

> {quote:title=Colin Maharaj wrote:}{quote}
>
> My question what kind of behavior would you expect
> if you mismatch new / delete as I described.

in an implementation optimized for maximal performance, new[] probably stores the size of the array at a negative offset, while new doesn't.

new[] + delete leads to lots of destructors not being called and probably to a failure in free() (since the pointer passed to free does not exactly match).
new + delete[] causes a random number of destructors to be called and the same failure in free() as above.

Of course, a fault-tolerant implementation could avoid this by semantically translating new as new[1] and delete as delete[].

--
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
2/5/2009 2:04:36 PM
Colin Maharaj <noreply@nohost.com> writes:

> My question what kind of behavior would you expect
> if you mismatch new / delete as I described.

Undefined behavior.

-- 
Chris (TeamB)
0
Chris
2/5/2009 2:50:46 PM
Moritz Beutel <> writes:

> in an implementation optimized for maximal performance, new[]
> probably stores the size of the array at a negative offset, while
> new doesn't.

A user can overload operator new and operator delete, while
simultaneously overloading operator new[] and operator delete[] to be
completely different and incompatible.  So even if the implementation
happens to provide something that works by accident when you mismatch
the operators, nothing ensures that the results will work.

Undefined behavior is undefined and should be treated as such, even if
you think you know what is going on behind the scenes it's very
dangerous to rely on it.  The only exception is if the compiler vendor
happens to document the precise behavior that occurs in the situation
on their compiler, in which case it's now defined for that compiler
(but you should use #ifdef's to ensure you don't accidently assume
that logic on other compilers.)

-- 
Chris (TeamB)
0
Chris
2/5/2009 2:53:50 PM
> {quote:title=Moritz Beutel wrote:}{quote}
> Of course, a fault-tolerant implementation could avoid this by semantically translating new as new[1] and delete as delete[].

Not if you are deleting a derived class instance with a virtual destructor through a base class pointer (valid for delete, invalid for delete[]).

{code}
struct base { virtual ~base();};
struct derived : public base { ~derived(); };
 
void fn()
{
  base *b1 = new derived();
  base *b2 = new derived[1];
 
 delete    b1; // ok... calls ~derived()
 delete [] b2; // undefined... would call ~base()
}
{code}

Vaclav
0
Vaclav
2/5/2009 4:31:37 PM
Vaclav Cechura <> wrote:

>Not if you are deleting a derived class instance with a virtual destructor through a base class pointer (valid for delete, invalid for delete[]).
>
>{code}
>struct base { virtual ~base();};
>struct derived : public base { ~derived(); };
> 
>void fn()
>{
>  base *b1 = new derived();
>  base *b2 = new derived[1];
> 
> delete    b1; // ok... calls ~derived()
> delete [] b2; // undefined... would call ~base()
>}
>{code}

Now what makes you think that? I mean, we've already posited undefined
behaviour, and now you're trying to define it!

(And in early versions of Zortech C++, delete and delete[] were actually
interchangeable.)

Now I'll agree that there are some *very* nasty bugs that you can run
into if you use a pointer-to-base to actually point to an array of
derived, and deletion is one of them. But it's the element size changing
that's the problem there.

Or have I missed something?

Alan Bellingham
-- 
Team Browns
ACCU Conference 2009: Wed 22 - Sat 25 April 2009, Oxford
0
Alan
2/5/2009 4:47:34 PM
"Colin Maharaj" <noreply@nohost.com> wrote in message 
news:77442@forums.codegear.com...

> My question what kind of behavior would you
> expect if you mismatch new / delete as I described.

It is undefined behavior.

-- 
Remy Lebeau (TeamB)
0
Remy
2/5/2009 6:41:59 PM
"Alan Bellingham" <alanb@episys.com> wrote in message 
news:77565@forums.codegear.com...
> Vaclav Cechura <> wrote:
>
>>Not if you are deleting a derived class instance with a virtual destructor 
>>through a base class pointer (valid for delete, invalid for delete[]).
>>
>>{code}
>>struct base { virtual ~base();};
>>struct derived : public base { ~derived(); };
>>
>>void fn()
>>{
>>  base *b1 = new derived();
>>  base *b2 = new derived[1];
>>
>> delete    b1; // ok... calls ~derived()
>> delete [] b2; // undefined... would call ~base()
>>}
>>{code}
>
> Now what makes you think that? I mean, we've already posited undefined
> behaviour, and now you're trying to define it!

no, this is different variant of UB:
5.3.5/3
.... In the second alternative (delete array) if the dynamic type of the 
object
to be deleted differs from its static type, the behavior is undefined.

> (And in early versions of Zortech C++, delete and delete[] were actually
> interchangeable.)

really? probably only for classes with trivial destructor

Cheers,
Serge
0
Sergiy
2/5/2009 8:20:56 PM
Hello,

> {quote:title=Chris Uzdavinis wrote:}{quote}
> 
> A user can overload operator new and operator delete, while
> simultaneously overloading operator new[] and operator delete[] to be
> completely different and incompatible.  So even if the implementation
> happens to provide something that works by accident when you mismatch
> the operators, nothing ensures that the results will work.

you can overload the allocators, but not the operators themselves, AFAIK. new and new[] could still attach a common metadata field (say, 0 when allocated with new and the array size when allocated with new[]), which delete would evaluate:
{code:cpp}
template <typename T>
    void pseudoHighLevelDelete (T* data)
{
    if (((unsigned*) data)[-1] == 0)
    {
        data->~T ();
        operator delete (data);
    }
    else
    {
        unsigned count = ((unsigned*) data)[-1];
        for (unsigned i = 0; i != count; ++i)
            data[i].~T ();
        operator delete[] (data);
    }
}
{code}


> Undefined behavior is undefined and should be treated as such, even if
> you think you know what is going on behind the scenes it's very
> dangerous to rely on it.

Of course. My impression was that the OP were just interested in the reasons.

--
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
2/5/2009 10:33:19 PM
Hello,

> {quote:title=Vaclav Cechura wrote:}{quote}
> > {quote:title=Moritz Beutel wrote:}{quote}
> > Of course, a fault-tolerant implementation could avoid this by semantically translating new as new[1] and delete as delete[].
> 
> Not if you are deleting a derived class instance with a virtual destructor through a base class pointer (valid for delete, invalid for delete[]).

right. But AFAICS, there is no difference in the undefined behaviour of delete[] arrayBaseClassPointer; and universal_delete arrayBaseClassPointer.

--
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
2/5/2009 10:36:25 PM
Moritz Beutel <> writes:

> you can overload the allocators, but not the operators themselves,
> AFAIK.

I'm not sure I follow what you are saying here, but if you mean to
suggest that I cannot replace the global operator new, or add an
overload for that operator for a particular class, then your
assumption is incorrect.  You can do that.

> new and new[] could still attach a common metadata field (say, 0
> when allocated with new and the array size when allocated with
> new[]), which delete would evaluate:

> {code:cpp}
> template <typename T>
>     void pseudoHighLevelDelete (T* data)
> {
>     if (((unsigned*) data)[-1] == 0)
>     {
>         data->~T ();
>         operator delete (data);
>     }
>     else
>     {
>         unsigned count = ((unsigned*) data)[-1];
>         for (unsigned i = 0; i != count; ++i)
>             data[i].~T ();
>         operator delete[] (data);
>     }
> }
> {code}

I get your idea.  But there are still problems, even if I'm just being
nit-picky.  C++ has a design philosophy that you shouldn't have to pay
for stuff you don't need or use.  The approach you're suggsting would
have a cost of more runtime checking (which is only useful in helping
debug code, since correct code wouldn't need it), and also more memory
usage.  For lots of small allocations, this could be prohibative.

Also, of course, if you are indexing element -1, then presumably the
raw memory is "over allocated", and new returned an address that is
actually offset into the allocated memory region.  As such, you'd
probably want to reverse the offset before deleting the memory, no?

-- 
Chris (TeamB)
0
Chris
2/5/2009 11:38:04 PM
Hello,

> {quote:title=Chris Uzdavinis wrote:}{quote}
> Moritz Beutel <> writes:
> 
> > you can overload the allocators, but not the operators themselves,
> > AFAIK.
> 
> I'm not sure I follow what you are saying here, but if you mean to
> suggest that I cannot replace the global operator new, or add an
> overload for that operator for a particular class, then your
> assumption is incorrect.  You can do that.

I know. But when you overload the operators new, new[], delete or delete[] for either the global namespace or a specific class, you merely implement custom memory allocators. The "hard stuff" done by new and delete (allocating constructors and destructors, storing metadata etc.) remains a language intrinsic which you cannot overload.
Of course, you can still override it using placement new.


> I get your idea.  But there are still problems, even if I'm just being
> nit-picky.  C++ has a design philosophy that you shouldn't have to pay
> for stuff you don't need or use.  The approach you're suggsting would
> have a cost of more runtime checking

Three ASM instructions. Just about enough for the C++ committee to introduce yet another dangerous but unneccessary distinction, such as delete[] is.


> (which is only useful in helping debug code, since correct code wouldn't need it)

What about make writing correct code easier?


> and also more memory usage.  For lots of small allocations, this could be prohibative.

True if you allocate immense lots of single objects. But if you ever get to a point where this seriously affects your memory usage, you would use a memory pool and placement new anyway - because in practice, the memory manager is the primary bottleneck.


> Also, of course, if you are indexing element -1, then presumably the
> raw memory is "over allocated", and new returned an address that is
> actually offset into the allocated memory region.  As such, you'd
> probably want to reverse the offset before deleting the memory, no?

Yes, of course :) I overlooked that.

--
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
2/6/2009 8:15:05 AM
Sergiy Kanilo <skanilo@hotmail.com> wrote:

>no, this is different variant of UB:
>5.3.5/3
>... In the second alternative (delete array) if the dynamic type of the object
>to be deleted differs from its static type, the behavior is undefined.

That looks to be the out for the fact that it will (very frequently)
break for arrays of more than one item.

>> (And in early versions of Zortech C++, delete and delete[] were actually
>> interchangeable.)
>
>really? probably only for classes with trivial destructor

Nope - it did work. Remember, it was very early, and the standard hadn't
been decided at that point. Implementing new and delete as being
effectively new[1] and delete[] shouldn't break anything, so long as you
actually define the effect of 5.3.5/5 *when applied to an array of one
element*.

OK, excepting that overloading the global new/delete/new[]/delete[]
operators won't be as expected.

And that code written with this cavalier attitude to delete/delete[] was
strictly non-portable and highly prone to breakage on other platforms.

Alan Bellingham
-- 
Team Browns
ACCU Conference 2009: Wed 22 - Sat 25 April 2009, Oxford
0
Alan
2/6/2009 9:38:47 AM
> {quote:title=Alan Bellingham wrote:}{quote}
> Now what makes you think that? 

I don't know "what" precisely are you addressing here.
If it's the "would call ~base()" part, then a simple try in the BCB2006 debbuger shows that ~base() gets really called. 

>I mean, we've already posited undefined behaviour, and now you're trying to define it!

If you look back at the original sentence I was replying too:
> {quote:title=Moritz Beutel wrote:}{quote}
> Of course, a fault-tolerant implementation could avoid this by semantically translating new as new[1] and delete as delete[].

you would see that we have been talking about a (obviously non-standard) falut-tolerant implementation that would all new and delete expressions treat as new [1] and delete []. I was just pointg out that this would not work if virtual destructors are in play.

> But it's the element size changing that's the problem there.

Of course it would be the main problem with regular arrays (more than one element), but in the specific case of the proposal using one element array we were discussing above the problem with the call to the wrong destructor has to be emphasized.

Vaclav
0
Vaclav
2/6/2009 12:11:43 PM
> {quote:title=Moritz Beutel wrote:}{quote}
> But AFAICS, there is no difference in the undefined behaviour of delete[] arrayBaseClassPointer; and universal_delete arrayBaseClassPointer.

The second case is not undefined if virtual destructors are used. See:
> {quote:title=ISO C++ Standard 5.3.5/3:}{quote}
>In the first alternative (delete object), if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand’s dynamic type and the static type shall have a virtual destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined.

Vaclav
0
Vaclav
2/6/2009 12:20:52 PM
Hello,

> {quote:title=Vaclav Cechura wrote:}{quote}
> 
> The second case is not undefined if virtual destructors are used.

In real C++:
{code:cpp}
struct VBase { virtual ~VBase (void) {} };
struct VDerived : VBase {};
struct Base {};
struct Derived : Base {};

delete static_cast <Base*> (new Derived); // undefined
delete static_cast <VBase*> (new VDerived); // ok
delete [] new VDerived[2]; // ok
delete [] static_cast <Base*> (new Derived[2]); // undefined
delete [] static_cast <VBase*> (new VDerived[2]); // undefined
{code}

Assuming that delete can be used for both arrays and normal pointers:
{code:cpp}
delete static_cast <Base*> (new Derived); // undefined
delete static_cast <VBase*> (new VDerived); // ok
delete new VDerived[2]; // ok
delete static_cast <Base*> (new Derived[2]); // undefined
delete static_cast <VBase*> (new VDerived[2]); // undefined
{code}

Where's the difference?

--
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
2/6/2009 12:52:28 PM
Vaclav Cechura <> writes:

> you would see that we have been talking about a (obviously
> non-standard) falut-tolerant implementation that would all new and
> delete expressions treat as new [1] and delete []. I was just pointg
> out that this would not work if virtual destructors are in play.

I wouldn't call it fault-tolerant.  A better name is "fault hiding".

>> But it's the element size changing that's the problem there.
>
> Of course it would be the main problem with regular arrays (more
> than one element), but in the specific case of the proposal using
> one element array we were discussing above the problem with the call
> to the wrong destructor has to be emphasized.

If we're writing a compiler that allowed new and new[] to be
intermixed to prevent possible problems, and we don't care about
wasting "just a little" memory, and we don't care about "a little
extra runtime" performance penalty (which seems to be some people's
preferences) we could go all the way and make the compiler work on
polymorphic arrays correctly as well.

1) every object has a virtual table, even primitive types.

2) every object has a virtual __sizeof() member function that reports
the size in bytes of the most derived type.

3) delete[]-ing an array would have the effect of something like this:

  // (untested, and just thinking out loud)

  template <typename T>
  void __smart_delete(T * array)
  {
    T * ptr = array;
    std::size_t num_elements = reinterpret_cast<int *>(array)[-1];
    for (std::size_t i = num_elements; i < num_elements; ++i)
    { 
      std::size_t obj_size = ptr->__sizeof();
      ptr->~T();
      ptr = reinterpret_cast<T*>(
               reinterpret_cast<char*>(ptr) + obj_size);
    }
    operator delete[](array);
  }

.... though it'd be a little more complicated because arrays need to
delete their elements in the REVERSE direction so that the last
allocated is the first deleted.  Since the sizes of the elements may
vary, and we only know the address of the first, we'd need to collect
an array of addresses to each element, and then iterate over that
array deleting elements.  Hmmm:

  // (untested, and just thinking out loud)

  template <typename T>
  void __smart_delete(T * array)
  {
    std::stack<T*> addrs;
    std::size_t num_elements = reinterpret_cast<int *>(array)[-1];

    // first build a stack of correct offsets
    for (std::size_t i = num_elements; i < num_elements; ++i)
    { 
      addrs.push(ptr);
      ptr = reinterpret_cast<T*>(
               reinterpret_cast<char*>(ptr) + ptr->__sizeof());
    }

    // now delete the elements
    while (!addrs.empty())
    {
      T * cur = addrs.top();
      cur->~T();
      addrs.pop();
    }

    operator delete[](array);
  }


There, does that approach make everyone happy?  :)  I think there
would be a revolt in the community if they tried to do this to our
language.   Heads would roll.

-- 
Chris (TeamB)
0
Chris
2/6/2009 2:31:39 PM
Vaclav Cechura <> wrote:

>you would see that we have been talking about a (obviously non-standard)
>falut-tolerant implementation that would all new and delete expressions
>treat as new [1] and delete []. I was just pointg out that this would
>not work if virtual destructors are in play.

What I was doing was asking you on what basis you were making this
statement, since it seemed unsubstantiated. If you can point at
something in the Standard apart from 5.3.5/5 (already addressed) that is
relevant, that would be interesting.

As I pointed out, I've pretty sure I encountered a pre-standard
implementation for which your statement was incorrect. A test program
with BCB5 shows that for BCB5 it *is* correct. 

I'm interested to know *why*, other than it's UB, and the compiler when
generating the destructor code for an array may safely assume it knows
the actual types of the array, because if it's *wrong*, the user has
invoked UB. Since (in a legal program) it therefore knows the actual
type, it is permitted to bypass the virtual function call mechanism in
the code underlying delete[] which calls the d'tors. Our hypothetical
compiler could use the vfunc mechanism for the first element, and the
non-vfunc one for any remaining.

I am not, by the way, recommending that C++ be changed to legitimise
this: I'm quite happy at the relative lack of overhead, and I have code
which actually would have to be rewritten if the language changed. I'm
certainly not suggesting that the OP should not balance his new/delete
call types correctly.

As an aside, I know people who would consider putting anything into an
array that isn't a value type to be anathema, and that a value type with
any virtual functions at all is also anathema.

Alan Bellingham
-- 
Team Browns
ACCU Conference 2009: Wed 22 - Sat 25 April 2009, Oxford
0
Alan
2/6/2009 2:54:38 PM
> {quote:title=Moritz Beutel wrote:}{quote}
> Assuming that delete can be used for both arrays and normal pointers:

This is not what you originally suggested. You intended to semantically translate every new to new[1] and delete to delete [].

> {code:cpp}
> delete static_cast <Base*> (new Derived); // undefined
> delete static_cast <VBase*> (new VDerived); // ok
> delete new VDerived[2]; // ok
> delete static_cast <Base*> (new Derived[2]); // undefined
> delete static_cast <VBase*> (new VDerived[2]); // undefined
> {code}
> 
> Where's the difference?

The difference is that according to your original proposal a fault-tolerant compiler would translate the code
{code}
delete static_cast <VBase*> (new VDerived); // ok
{code}
to
{code}
delete [] static_cast <VBase*> (new VDerived[1]); // ?
{code}
which means that the semantical translation itself is not enough and it would require more changes in the compiler.


Vaclav
0
Vaclav
2/6/2009 4:21:49 PM
"Alan Bellingham" <alanb@episys.com> wrote in message 
news:77884@forums.codegear.com...
> Sergiy Kanilo <skanilo@hotmail.com> wrote:

> Nope - it did work. Remember, it was very early, and the standard hadn't
> been decided at that point. Implementing new and delete as being

sure, if we don't define how it should behave, it probably behaves as it 
should :)

> effectively new[1] and delete[] shouldn't break anything, so long as you
> actually define the effect of 5.3.5/5 *when applied to an array of one
> element*.

presume we have

struct B { virtual ~B(); };
struct A : B {};

    delete (B*) new A;

should be ok, but if we replace delete with delete[] and new with new[1]

    delete[](B*)new A[1];

we'll have definite UB.

Cheers,
Serge
0
Sergiy
2/6/2009 7:03:26 PM
Hello,

> {quote:title=Vaclav Cechura wrote:}{quote}
> > {quote:title=Moritz Beutel wrote:}{quote}
> > Assuming that delete can be used for both arrays and normal pointers:
> 
> This is not what you originally suggested. You intended to semantically translate every new to new[1] and delete to delete [].

you are right about that: I misformulated my suggestion at the beginning.
The possible implementation of a universally applicable delete which I posted in response to Chris should explain what I meant: new and new[] store metadata at ((unsigned*)data)[-1], which is evaluated by delete. Thus, the distinction between overloads of operator new/delete and operator new[]/delete[] can be kept up, and no further compiler changes are required.

Better? :)

--
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
2/6/2009 7:51:23 PM
Sergiy Kanilo <skanilo@hotmail.com> writes:

> "Alan Bellingham" <alanb@episys.com> wrote in message 
> news:77884@forums.codegear.com...
>> Sergiy Kanilo <skanilo@hotmail.com> wrote:
>
>> Nope - it did work. Remember, it was very early, and the standard hadn't
>> been decided at that point. Implementing new and delete as being
>
> sure, if we don't define how it should behave, it probably behaves as it 
> should :)
>
>> effectively new[1] and delete[] shouldn't break anything, so long as you
>> actually define the effect of 5.3.5/5 *when applied to an array of one
>> element*.
>
> presume we have
>
> struct B { virtual ~B(); };
> struct A : B {};
>
>     delete (B*) new A;
>
> should be ok, but if we replace delete with delete[] and new with new[1]
>
>     delete[](B*)new A[1];
>
> we'll have definite UB.

Probably not in this example.  :)  (Well, according to the standard,
yes, but since we're talking about WHY it's a problem, the symptoms
are not shown here.)

The two requirements are 1) that the sizeof(A) > sizeof(B), and 2)
that N>1 where N is the size of the array.

If we only have case 1 above, then the address of A* and B* are the
same, and there is only one element so the pointer never gets "off".

If we only have case 2 above, then we have many elements but they're
the same size, so incrementing the pointer never causes an invalid
address to be calculated.

But if we have case 1 and case 2 both occur, then when we move to
element 2, we only advance the pointer by sizeof(B) (the base object)
but that's not enough of an offset since sizeof(A) is bigger.  Thus,
we get off but the amount of the difference in size, and delete
objects in the wrong place.

-- 
Chris (TeamB)
0
Chris
2/6/2009 8:26:07 PM
Reply:

Similar Artilces:

Deletes are not being deleted.
Using ASA 7.03 I am having a problem in deleting field service orders that have been completed. Just getting started with sync so I am probably making a dumb mistake or just leaving out a step. The download_delete_cursor script is: Select ordernumber from ServiceOrderEntryMaster where Tech = ? and Order_Complete = 'Y' This based on the verbose reply from the MobiLink Synchronization server is picking the correct work order ( number 326 ) and showing a Delete Row line in the log. But the work order is not being deleted on the remote side. What could I be doing wron...

superreview cancelled: [Bug 323109] deleted attachment: "Deleted: " vs "Deleted:", not localizable : [Attachment 210044] proposed fix
Magnus Melin <mkmelin+mozilla@iki.fi> has cancelled David Bienvenu <bienvenu@nventure.com>'s request for superreview: Bug 323109: deleted attachment: "Deleted: " vs "Deleted:", not localizable https://bugzilla.mozilla.org/show_bug.cgi?id=323109 Attachment 210044: proposed fix https://bugzilla.mozilla.org/attachment.cgi?id=210044&action=edit ...

PTR delete == A delete
Hi, i want to delete PTR record but not de A record. if i delete the PTR the A-record is also deleted. (use iManger & DNS console) is there a way to only delete PTR-record's? Niels van de Haar Systeembeheer In article <QwvDd.17151$Ei5.2128@prv-forum2.provo.novell.com>, wrote: > if i delete the PTR the A-record is also deleted. (use iManger & DNS > console) > What version of NAMED? NetWare? Service Pack? bd NSC Volunteer SysOp Netware 6.5 Sp2 (named from that netware sp) >>> Brad Doster<bd@NSCSysOps.net> 7-1-2005 17:1...

Gridview Delete not Deleting
I am trying to use a command button to delete a row from a gridview. When I click the command button though, the page posts but my record is still there... no errors, just nothing seems to happen. Below is what I think is the relevant code, let me know if you need to see anything else.  I'm kinda new to working with gridview objects, it would be nice if I could see what SQL command is acctually ran... maybe there are other things I can check too, I'm just not sure how.   <asp:GridView ID="GridView1" runat="server" AllowSorting="True"&nbs...

Delete Confirm not Deleting
I followed the instruction in this tutorial (http://asp.net/learn/dataaccess/tutorial22vb.aspx) to add delete confirm to a GridView's FieldCommand Delete button.  It will delete the record if I comment out this code but not if I don't.  I get the confirm dialog and a postback but the record is not deleted.  DataKeyNames are set.  What's the deal?Here's the code.Protected Sub GridView1_RowDataBound(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.GridViewRowEventArgs)         'Delete Confirm     &nbs...

Deleted items not deleting
We are running GW 7.0.1 W2K3 server agents and 7.0.1 workstation clients. Some users have thousands of items in their trash and other folders within their account. The problem is when you select all the messages and delete them, they don't actually delete. They stay in the users client. An expire/reduce doesn't do anything either. We also tried setting up in consoleone under groupwise>client>environment>cleanup -- the clients to automatically delete items and that didnt' work either. Does anyone have any suggestions??? Will, i will try to run a GW check...

Insert/Delete/Delete all rows
Hi Neither in data window painter nor in data base painter I can Insert, Delete and Delete all Rows for a table. These Items are in both painters gray and can,t been selected. Is something wrong on my installation of PB? PB 7.02 (Build 8030) Can someone help me? Thanks Taghi Pouradjam Does your table have a primary key defined? -- <hopethishelps /> Roy Kiesler [TeamSybase] mySybase -- http://my.sybase.com "Taghi Pouradjam" <pouradjam@oasys.de> wrote in message news:OzIH97fiAHA.128@forums.sybase.com... > Hi > > Neither in data wi...

How to delete replica and how many to delete??
I am still fighting with trying to get trees merged. I finally got through the last problem, but now I get a message when using DSMERGE utility under Imanager using the DSMERGE Wizard: "FOr merge to be successful, on the target tree there can only be one copy of the root replica. Remove allother replicas and retry the operation." The target tree has two servers. The main server has two replicas: 1= .[ROOT]. with Master as replica type 2= .HANGELS with Subordinate as replica type The other server has two replicas also: 1= .HANGELS with master as replica t...

Deleting or not-deleting users from Vault.
Hi All, There is a mixed feeling among everyone about deleting or not-deleting inactive users from the Identity Vault of an IDM system. I have come across different opinions from different groups of people that I have interacted and discussed on this topic. Will like to collect the views / best practices being followed in industry for the benefit of everyone in the IDM world. Should we delete inactive users from the Vault, if so when? Sometimes this depends on business decisions and HR policy but the question is, when is it technically right to delete accounts. One school of...

Deleting files from other mailboxes after deleting from your own.
I appoligize if this is the wrong forum, but it seemed closest to the problem we're having. Is there a way to delete mail from other users mailboxes after you have deleted it from your own, but, accidently didn't specify all mailboxes? Unfortunately, someone here sent out a sensitive email, reacted quickly, and made a mistake. Any help is greatly apprecisated. Thanks Restore the mailbox, create a restore area and retrieve the mail from the backup. Then you should be able to retract it again. > I appoligize if this is the wrong forum, but it seemed close...

Junk Mail..To delete or not to delete
I have read various opinions on this....to trian Junk Mail does one leav all such identified mail in Junk Folder or can one continously delete them all???? ...

delete from server, when deleted from trash
Now there's the option "delete from server, when deleted from Inbox" which is no use when you want to keep your valuable messages that you organized over different folder. Gill Bates wrote: > Now there's the option "delete from server, when deleted from Inbox" > which is no use when you want to keep your valuable messages that you > organized over different folder. See <http://bugzilla.mozilla.org/show_bug.cgi?id=226839>. -- Robert Mohr mohr.42@osu.edu <http://www.mozilla.org/wishlist-faq.html> <http://extensionroom.mozd...

Deleted WEBAC70A wont delete
I have tried dsrepair -a -xk3 and checked external referances and there are 0 purgeable anything but still WEBAC70A shows up in the DSBROWSE and says its a deleted item???? So i am scratching my head. Netware 6.5 SP8 Edirectory 8.8SP4 Any ideas? -- hpoling ------------------------------------------------------------------------ Everything is deleted now in dsbrowse consoleone and i have 0 errors in dsrepair external referances included. But when i try to add it again it say it already exists HELP, Thanks -- hpoling -----------------------------------------...

Delete row and delete from table
Hi I need, after delete a grid row, execute a delete statmentProtected Sub GridView1_RowCommand(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.GridViewCommandEventArgs) Handles GridView1.RowCommand Dim advogado As StringIf (e.CommandName = "Apagar") Thenadvogado = RTrim(e.CommandArgument.ToString)Apaga_Processos(advogado)End Ifend subPrivate Sub Apaga_Processos(ByVal advogado As String)Dim conn As SqlConnectionDim comm As SqlCommandDim connectionString As String = ConfigurationManager.ConnectionStrings("mssql2.tuganet.com").ConnectionStringconn = New Sql...

Web resources about - delete vs []delete - embarcadero.cppbuilder.cpp

Delete key - Wikipedia, the free encyclopedia
, known less ambiguously as forward delete ) discards the character ahead of the cursor 's position, moving all following characters one position ...

Facebook Fined $77K by Argentine Court for Failing to Delete Alleged Defamatory Groups
... mess in Argentina , as PanAm Post reported that a Rosario court ordered the social network to pay compensation of $77,000 for failing to delete ...

Facebook adds search history to Activity Log so users can delete queries
... in users’ Activity Logs. The feature will be rolled out to all users in the next few weeks. The feature allows for users to view and delete ...

Tweets MPs Delete (@deletedbyMPs) on Twitter
Sign in Sign up You are on Twitter Mobile because you are using an old version of Internet Explorer. Learn more here Tweets MPs Delete @ deletedbyMPs ...

Oren Jacob's answer to Pixar Animation Studios: Did Pixar accidentally delete Toy Story 2 during production ...
Oren Jacob's answer: Hi everyone, I'm the Oren Jacob in the video. Hopefully I can offer some first person color commentary about the video above ...

Tweeticide - Delete All of Your Twitter Tweets at Once! on the App Store on iTunes
Get Tweeticide - Delete All of Your Twitter Tweets at Once! on the App Store. See screenshots and ratings, and read customer reviews.

Delete, and I mean it! - Flickr - Photo Sharing!
I bought a new keyboard at work because I spilled cereal on the previous one and some of the keys stopped working. The new one has a giant delete ...

Facebook deletes Perth page dedicated to school fights
A page filled with videos of Perth school students fighting has been deleted by Facebook, as a video of people brawling in Perth CBD hit headlines. ...

Viber now lets you attach files, delete messages and more
... and public chat forwarding in late September , the app keeps growing. In an update today, Nov. 24, Viber users can now attach files, delete ...

Bank of America gets Twitter to delete journalist’s joke, says he violated copyright
The founding editor of Business Insider UK, Jim Edwards , had a bank delete two of his tweets today. In an e-mail, Bank of America told Edwards ...

Resources last updated: 12/28/2015 6:23:53 AM