Dear fellow Access 2003 Users,
Is there a way to trim all of the fields in a table in one swoop using
VBA (preferred) or a query? Right now, I am using an update query and
updating EACH field to it's trimmed counterpart. Any ideas? Thanks!
Kevin
36  6491 
Something like this will work --
Dim Db As DAO.Database
Dim Rst As DAO.Recordset
Set Db = CurrentDb()
Set Rst = Db.OpenRecordset("MyTable")
With Rst
!Field1Name = Trim( !Field1Name)
!Field2Name = Trim( !Field2Name)
---
etc
.Close
End With
Set Rst = Nothing
Set Db = Nothing
--
PC Datasheet
Your Resource For Help With Access, Excel And Word Applications re******@pcdatasheet.com www.pcdatasheet.com
If you can't get the help you need in the newsgroup, I can help you for a
very reasonable fee. Over 1000 Access users have come to me for help.
Need a month calendar or 7 day calendar? Need appointment scheduling? Need
room reservations scheduling? Need employee work scheduling? Contact me!
"No Spam" <no****@earthlink.net> wrote in message
news:o2********************************@4ax.com... Dear fellow Access 2003 Users,
Is there a way to trim all of the fields in a table in one swoop using
VBA (preferred) or a query? Right now, I am using an update query and
updating EACH field to it's trimmed counterpart. Any ideas? Thanks!
Kevin
PC Datasheet wrote: Something like this will work --
No it won't. Not only are you missing rs.edit and rs.update which are
required when editing recordset data, but even if it did work it'd only
do one row at best. It also requires that all the fieldnames be typed
into the code, at which point you're probably better off just doing and
update...set in SQL.
Here's a little function to get the job done;
Function TrimIt()
Dim Db As Database
Dim Rs As Recordset
Dim fld As Field
Set Db = CurrentDb()
Set Rs = Db.OpenRecordset("MyTable")
While Not Rs.EOF
For Each fld In Rs.Fields
With Rs
.Edit
fld.Value = Trim(fld.Value)
.Update
End With
Next fld
Rs.MoveNext
Wend
Rs.Close
Set Rs = Nothing
Set Db = Nothing
End Function
PC Datasheet wrote: If you can't get the help you need in the newsgroup, I can help you for a
very reasonable fee.
Oh, and by the way Kevin... No charge.
You are missing the .Edit and the .Update and you are not looping through
the records.
Your post should impress your legions of fans.
John... Visio MVP
"PC Datasheet" <no****@nospam.spam> wrote in message
news:1i****************@newsread2.news.atl.earthli nk.net... Something like this will work --
Dim Db As DAO.Database
Dim Rst As DAO.Recordset
Set Db = CurrentDb()
Set Rst = Db.OpenRecordset("MyTable")
With Rst
!Field1Name = Trim( !Field1Name)
!Field2Name = Trim( !Field2Name)
---
etc
.Close
End With
Set Rst = Nothing
Set Db = Nothing
PC Datasheet
Your Resource For Help With Access, Excel And Word Applications
NOT!
Now this is a new tactic. Supply defective code, then offer to fix it for a
small fee.
"PC Datasheet" <no****@nospam.spam> wrote in
news:1i****************@newsread2.news.atl.earthli nk.net: Something like this will work --
Dim Db As DAO.Database
Dim Rst As DAO.Recordset
Set Db = CurrentDb()
Set Rst = Db.OpenRecordset("MyTable")
With Rst
!Field1Name = Trim( !Field1Name)
!Field2Name = Trim( !Field2Name)
---
etc
.Close
End With
Set Rst = Nothing
Set Db = Nothing
I would never do this kind of thing in this manner (we all recognize
the problems with the air code above, so I won't bother to correct
them).
I would use the FIELDS collection to generate a SQL UPDATE query for
each field. That will be *much* faster than editing each field one
record at a time.
I'd also make sure that I based my recordset not on the table, but
on a SQL string that included only the fields that are trimmable
(e.g., leaving out all the numeric fields).
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"PC Datasheet" <no****@nospam.spam> schreef in bericht news:1i****************@newsread2.news.atl.earthli nk.net... Something like this will work --
Again a wrong answer. You are getting a high score!!
You did not give it *too* much thought ...
Nah ..., apparently you only posted this to advertise again.
If you can't get the help you need in the newsgroup, I can help you for a
very reasonable fee. Over 1000 Access users have come to me for help.
These 1000 (if at all a real figure..) is only the result of
-- 4 years abusing the newsgroups.
-- 4 years blatantly advertising and job hunting.
You only care about making money, and you act as if the groups are your private hunting ground.
So why would ANYBODY ever trust a person like you and hire you?
************************************************** ******
Need a month calendar or 7 day calendar? Need appointment scheduling? Need
room reservations scheduling? Need employee work scheduling? Contact me!
Need a psychiatrist ...Contact me!
Arno R
David W. Fenton wrote: I would use the FIELDS collection to generate a SQL UPDATE query for
each field. That will be *much* faster than editing each field one
record at a time.
Imagine for a moment that you've been asked to empty a bottle of water.
It's the only time you'll need to empty this bottle of water because
the empty bottle is the goal, not the act of emptying it. Having not
emptied a bottle of water before, you ask someone how to go about it.
They inform you that an easy way to empty the bottle is simply to pour
the water out, which you do and hey presto.. empty bottle. Someone
else comes along and suggests that a faster way to empty the bottle
would be to spin it first, which creates a vortex inside the bottle and
the water flows out much faster and smoother because air is able to
enter the bottle via the hole created by the vortex and thus does not
impede the flow of water as it equalizes the vacuum (negative pressure)
created by the voiding water.
You hold up the empty bottle and say "It's all good bro.. bottle's
empty".
I'd also make sure that I based my recordset not on the table, but
on a SQL string that included only the fields that are trimmable
(e.g., leaving out all the numeric fields).
Yes, or you could test each field's "type" property before building
your update string to make sure you were only updating fields of type
'10' and not '4' etc..... which would mean that your code would work
on any table (which could be passed into the function as a variable)
and you wouldn't have to enter all the fieldnames you wanted to update.
This is fun, we could go round and round all day long until we come up
with the *perfect* methodology. Meanwhile, Kevin has trimmed all the
fields in his table and probably won't be back to read this thread.
"Wolf" <sp*************@hotmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
PC Datasheet wrote: Something like this will work --
No it won't. Not only are you missing rs.edit and rs.update which are
required when editing recordset data, but even if it did work it'd only
do one row at best. It also requires that all the fieldnames be typed
into the code, at which point you're probably better off just doing and
update...set in SQL.
Here's a little function to get the job done;
Function TrimIt()
Dim Db As Database
Dim Rs As Recordset
Dim fld As Field
Set Db = CurrentDb()
Set Rs = Db.OpenRecordset("MyTable")
While Not Rs.EOF
For Each fld In Rs.Fields
With Rs
.Edit
fld.Value = Trim(fld.Value)
.Update
End With
Next fld
Rs.MoveNext
Wend
Rs.Close
Set Rs = Nothing
Set Db = Nothing
End Function
PC Datasheet wrote: If you can't get the help you need in the newsgroup, I can help you for
a very reasonable fee.
Oh, and by the way Kevin... No charge.
IMHO, an excellent solution. I think, however, David Fenton makes a good
point. Rather than building the recordset directly from the table, use a
SQL that selects only the text fields.
You forgot one of the important features of newsgroups. There is a crowd of
people watching the persons giving instructions and the one pouring the
water. So even though the OP has poured out his water, others may have a
similar requirement, but have thousands of bottles. They can now chose from
a variety of methods. (Or turn around and tell others it was their idea)
John... Visio MVP
"Randy Harris" <ra***@SpamFree.com> wrote in
news:bb**************@newssvr19.news.prodigy.com:
"Wolf" <sp*************@hotmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
PC Datasheet wrote: > Something like this will work --
No it won't. Not only are you missing rs.edit and rs.update
which are required when editing recordset data, but even if
it did work it'd only do one row at best. It also requires
that all the fieldnames be typed into the code, at which
point you're probably better off just doing and update...set
in SQL.
Here's a little function to get the job done;
Function TrimIt()
Dim Db As Database
Dim Rs As Recordset
Dim fld As Field
Set Db = CurrentDb()
Set Rs = Db.OpenRecordset("MyTable")
While Not Rs.EOF
For Each fld In Rs.Fields
With Rs
.Edit
fld.Value = Trim(fld.Value)
.Update
End With
Next fld
Rs.MoveNext
Wend
Rs.Close
Set Rs = Nothing
Set Db = Nothing
End Function
PC Datasheet wrote: > If you can't get the help you need in the newsgroup, I can
> help you for a > very reasonable fee.
Oh, and by the way Kevin... No charge.
IMHO, an excellent solution. I think, however, David Fenton
makes a good point. Rather than building the recordset
directly from the table, use a SQL that selects only the text
fields.
or just test: IF fld.type = dbText then...
You dont want to trim a double precision number :^)
--
Bob Quintal
PA is y I've altered my email address.
Yep that's the difference between asking a housewife and a lab technician.
You can ask your mate down the computer club or David Fenton.
Part of the point of Newsgroups such as this is to go round and round until
you come up with the best fit (rather than perfect) methodology.
Imagine in a couple of years time someone has a requirement to clean up data
on a regular basis, they search Google and find this thread, they read the
thread and realise that for their purposes David's suggestion is best, they
then don't come in here and post a question thus giving David (and you and
me) the opportunity to answer someone else with a different question.
--
Terry Kreft
"Wolf" <sp*************@hotmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
David W. Fenton wrote: I would use the FIELDS collection to generate a SQL UPDATE query for
each field. That will be *much* faster than editing each field one
record at a time.
Imagine for a moment that you've been asked to empty a bottle of water.
It's the only time you'll need to empty this bottle of water because
the empty bottle is the goal, not the act of emptying it. Having not
emptied a bottle of water before, you ask someone how to go about it.
They inform you that an easy way to empty the bottle is simply to pour
the water out, which you do and hey presto.. empty bottle. Someone
else comes along and suggests that a faster way to empty the bottle
would be to spin it first, which creates a vortex inside the bottle and
the water flows out much faster and smoother because air is able to
enter the bottle via the hole created by the vortex and thus does not
impede the flow of water as it equalizes the vacuum (negative pressure)
created by the voiding water.
You hold up the empty bottle and say "It's all good bro.. bottle's
empty".
I'd also make sure that I based my recordset not on the table, but
on a SQL string that included only the fields that are trimmable
(e.g., leaving out all the numeric fields).
Yes, or you could test each field's "type" property before building
your update string to make sure you were only updating fields of type
'10' and not '4' etc..... which would mean that your code would work
on any table (which could be passed into the function as a variable)
and you wouldn't have to enter all the fieldnames you wanted to update.
This is fun, we could go round and round all day long until we come up
with the *perfect* methodology. Meanwhile, Kevin has trimmed all the
fields in his table and probably won't be back to read this thread.
On Tue, 15 Nov 2005 15:38:23 GMT, No Spam <no****@earthlink.net> wrote: Dear fellow Access 2003 Users,
Is there a way to trim all of the fields in a table in one swoop using
VBA (preferred) or a query? Right now, I am using an update query and
updating EACH field to it's trimmed counterpart. Any ideas? Thanks!
Kevin
Sub TrimTableAllFields(strTableName As String)
Dim strSQL As String
Dim db As Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
On Error GoTo HandleIt
strSQL = "UPDATE [" & strTableName & "] SET "
Set db = CurrentDb()
Set tdf = db.TableDefs(strTableName)
For Each fld In tdf.Fields
If fld.Type = dbText Then
strSQL = strSQL & "[" & fld.Name & "] = Trim([" & fld.Name & "]), "
End If
Next fld
'get rid of last comma and add ;
strSQL = Left(strSQL, Len(strSQL) - 2) & ";"
db.Execute strSQL, dbFailOnError
OutHere:
If Not (fld Is Nothing) Then Set fld = Nothing
If Not (tdf Is Nothing) Then Set tdf = Nothing
If Not (fld Is Nothing) Then Set db = Nothing
Exit Sub
HandleIt:
Select Case Err
Case 0
Resume Next
Case Else
MsgBox Err & " " & Err.Description, vbOKOnly, "Error"
Resume OutHere
End Select
End Sub
John Marshall, MVP wrote: You forgot one of the important features of newsgroups. There is a crowd of
people watching the persons giving instructions and the one pouring the
water. So even though the OP has poured out his water, others may have a
similar requirement, but have thousands of bottles. They can now chose from
a variety of methods. (Or turn around and tell others it was their idea)
Should raise the price of the cd by a half-a-buck or so I'd think.
"Wolf" <sp*************@hotmail.com> wrote in
news:11**********************@g47g2000cwa.googlegr oups.com:
David W. Fenton wrote: I would use the FIELDS collection to generate a SQL UPDATE query
for each field. That will be *much* faster than editing each
field one record at a time.
Imagine for a moment that you've been asked to empty a bottle of
water. It's the only time you'll need to empty this bottle of
water because the empty bottle is the goal, not the act of
emptying it. Having not emptied a bottle of water before, you
ask someone how to go about it. They inform you that an easy way to
empty the bottle is simply to pour the water out, which you do
and hey presto.. empty bottle. Someone else comes along and
suggests that a faster way to empty the bottle would be to spin it first,
which creates a vortex inside the bottle and the water flows out
much faster and smoother because air is able to enter the bottle
via the hole created by the vortex and thus does not impede the
flow of water as it equalizes the vacuum (negative pressure)
created by the voiding water. You hold up the empty bottle and
say "It's all good bro.. bottle's empty".
Assume for the moment that a couple of days from now you encounter
another bottle that needs emptying. I'd also make sure that I based my recordset not on the table,
but on a SQL string that included only the fields that are
trimmable (e.g., leaving out all the numeric fields).
Yes, or you could test each field's "type" property before
building your update string to make sure you were only updating
fields of type '10' and not '4' etc..... which would mean that
your code would work on any table (which could be passed into the
function as a variable) and you wouldn't have to enter all the
fieldnames you wanted to update.
This is fun, we could go round and round all day long until we
come up with the *perfect* methodology. Meanwhile, Kevin has
trimmed all the fields in his table and probably won't be back to
read this thread.
Well, fuck you.
If you don't want to know anything about best practicies and
efficiency, then why are you here in the first place?
By posting a more efficient solution, I have not in any way
prevented you from accomplishing the task manually or by some other
less efficient method.
And, of course, I wasn't just answering the question for *your*
benefit.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Bob Quintal <rq******@sympatico.ca> wrote in
news:Xn**********************@207.35.177.135: "Randy Harris" <ra***@SpamFree.com> wrote in
news:bb**************@newssvr19.news.prodigy IMHO, an excellent solution. I think, however, David Fenton
makes a good point. Rather than building the recordset
directly from the table, use a SQL that selects only the text
fields.
or just test: IF fld.type = dbText then...
You dont want to trim a double precision number :^)
If I were writing a fully generic routine for this and knew for a
fact that I was always going to want to trim all the text fields in
a table, I'd test the field type.
If I'm doing a one-off or if I want the ability to choose which
textfields to test, I'd do it with a SQL strin that selects the
relevant fields.
I could conceive of a function that takes a SQL string as a
parameter, and if it starts with SELECT, it would just use the
FIELDS collection, while if it didn't have it (and was just a table
name), it would check the TableDef and test the field types.
Clearly, we're now looking at two subroutines, the outer one for
generating the list of fields, and the inner one for operating on
those fields. Of maybe even 3, with different subroutines for each
type of field list generation, and then the inner subroutine that
processes each field.
Another advantage here is that if you architect it right, you would
then have the option of doing a Trim() or a SttConv() or anything
else that you might want to do to a set of fields within a table.
But for a one-off, I'd just define the relevant fields in the
SELECT
and then walk through all the fields, without testing.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Wayne Gillespie <be*****@NOhotmailSPAM.com.au> wrote in
news:7h********************************@4ax.com: On Tue, 15 Nov 2005 15:38:23 GMT, No Spam <no****@earthlink.net>
wrote:
Dear fellow Access 2003 Users,
Is there a way to trim all of the fields in a table in one swoop
using VBA (preferred) or a query? Right now, I am using an
updatequery and updating EACH field to it's trimmed counterpart. Any
ideas? Thanks!
Kevin
Sub TrimTableAllFields(strTableName As String)
Dim strSQL As String
Dim db As Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
On Error GoTo HandleIt
strSQL = "UPDATE [" & strTableName & "] SET "
Set db = CurrentDb()
Set tdf = db.TableDefs(strTableName)
For Each fld In tdf.Fields
If fld.Type = dbText Then
strSQL = strSQL & "[" & fld.Name & "] = Trim([" &
fld.Name & "]), "
End If
Next fld
'get rid of last comma and add ;
strSQL = Left(strSQL, Len(strSQL) - 2) & ";"
You have a problem here. You need WHERE [field[ Is Not Null as a
condition for each query.
If you have that condition, then it's likely that running multiple
queries will be faster than running one big one, since it won't
have
to update all the fields.
db.Execute strSQL, dbFailOnError
OutHere:
If Not (fld Is Nothing) Then Set fld = Nothing
If Not (tdf Is Nothing) Then Set tdf = Nothing
If Not (fld Is Nothing) Then Set db = Nothing
Exit Sub
Why are you testing for Nothing and then setting to Nothing? Why
not
just do it?
The only reason I know of to test for Nothing is if you need to
close something, and the only one of these that in this code can be
closed is the tdf. So I'd have:
OutHere:
Set fld = Nothing
If Not (tdf Is Nothing) Then
tdf.Close
Set tdf = Nothing
End If
Set db = Nothing
Exit Sub
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Tue, 15 Nov 2005 19:49:12 -0600, "David W. Fenton" <dX********@bway.net.invalid> wrote: Sub TrimTableAllFields(strTableName As String)
Dim strSQL As String
Dim db As Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
On Error GoTo HandleIt
strSQL = "UPDATE [" & strTableName & "] SET "
Set db = CurrentDb()
Set tdf = db.TableDefs(strTableName)
For Each fld In tdf.Fields
If fld.Type = dbText Then
strSQL = strSQL & "[" & fld.Name & "] = Trim([" &
fld.Name & "]), "
End If
Next fld
'get rid of last comma and add ;
strSQL = Left(strSQL, Len(strSQL) - 2) & ";"
You have a problem here. You need WHERE [field[ Is Not Null as a
condition for each query.
There is no need for a WHERE clause to handle Nulls.
Null values will be ignored in the update.
Try it.
"PC Datasheet" <no****@nospam.spam> wrote in message
news:1i****************@newsread2.news.atl.earthli nk.net... Something like this will work --
<snip jibberish>
Clients beating a path to your door with this? Probably, but only to demand
a refund.
> > This is fun, we could go round and round all day long until we
come up with the *perfect* methodology. Meanwhile, Kevin has
trimmed all the fields in his table and probably won't be back to
read this thread.
Well, fuck you.
Shame on you David. Do you kiss your mother with that mouth?
Your lack of ability to articulate and your basis of self worth on your
"status" in this newgroup does not give you the right of verbal abuse
every time your ego is bruised.
No, I am back (and impressed!). Thank you very much!
On 15 Nov 2005 14:18:06 -0800, "Wolf" <sp*************@hotmail.com>
wrote:
David W. Fenton wrote:
Meanwhile, Kevin has trimmed all the
fields in his table and probably won't be back to read this thread.
I respect those who post their code!
Who are you and what did you do with Terry Kreft?
Should we test these fields to see if they are already in trimmed state
or not?
In that case we could trim only one field at a time, right?
It would be more efficient to trim all the trimmable fields at the same
time?
What does JET actually do when we update a record. Does it write over
the data in the file or does it mark it for exclusion and write a new
record?
And if it does the latter should we check the relationships on the
table and if there's noithing crucial there just append the trimmed
records and delete the non-trimmed ones?
Gee, maybe we should open the file with low level DOS functions and
edit out the spaces with REGEX? That would be purty perfect, now
wouldn't it? Oh yeah, you have to fill up those pages properly, huh?
Maybe not ....
And what about binary fields? Are binary fields where the first byte or
last byte is 20 (hex) trimmed or not trimmed?
memo fields?
How does untrimmed data get into a text field anyway?
When we trim the data in the field are we storing a calculation?
Eeeeeeeeek! Shouldn't we just leave the data as is and Trim it when
rerquired?
And what about the Space Religion where everyones name begins with a
space? How shall we deal with these names? Could someone's name be '
Wolf" or even ' '? Isn't that guaranteed?
Well, probably there are other significant questions which need to be
addressed in getting that perfect solution. In the meantime, if you're
on the side of, "let's just slap something together and trim the damn
fields", I'm with you.
If not, then I'm not!
There wasn't a hell of a lot wrong with Steve's reply that a little
code fixing wouldn't cure (and stopping with the stupid advertising ...
geez Steve most of the business you could would pick up here is nickel
and dime crap, why bother?) and which of us hasn't posted some bad code
here? (Oh, the ones who are experts on code but rarely or never post
full code solutions! Sorry, I forgot about them.)
Of course, I'd love to see the PERFECT solution and the FASTEST. And I
hope those purists who promote that will post it!
Shut up, Lyle!
David W. Fenton wrote: Well, fuck you.
If you don't want to know anything about best practicies and
efficiency, then why are you here in the first place?
By posting a more efficient solution, I have not in any way
prevented you from accomplishing the task manually or by some other
less efficient method.
What am I missing here? Why can't I find this "more efficient
solution"? Geez I am getting really old! You mean you posted the
perfect procedure for this and I missed it?
Could you post it again, David? Right from the Sub ______ or Function
_______ to the End Sub or the End Function so I don't miss anything.
"Wolf" <sp*************@hotmail.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com: >
> This is fun, we could go round and round all day long until we
> come up with the *perfect* methodology. Meanwhile, Kevin has
> trimmed all the fields in his table and probably won't be back
> to read this thread.
Well, fuck you.
Shame on you David. Do you kiss your mother with that mouth?
Your lack of ability to articulate and your basis of self worth on
your "status" in this newgroup does not give you the right of
verbal abuse every time your ego is bruised.
You'll notice that I don't say such things to people who behave
civilly in the first place.
You did not.
So, you won't ever get any of my assistance again.
<PLONK>
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Wayne Gillespie <be*****@NOhotmailSPAM.com.au> wrote in
news:r7********************************@4ax.com: On Tue, 15 Nov 2005 19:49:12 -0600, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
Sub TrimTableAllFields(strTableName As String)
Dim strSQL As String
Dim db As Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
On Error GoTo HandleIt
strSQL = "UPDATE [" & strTableName & "] SET "
Set db = CurrentDb()
Set tdf = db.TableDefs(strTableName)
For Each fld In tdf.Fields
If fld.Type = dbText Then
strSQL = strSQL & "[" & fld.Name & "] = Trim([" &
fld.Name & "]), "
End If
Next fld
'get rid of last comma and add ;
strSQL = Left(strSQL, Len(strSQL) - 2) & ";"
You have a problem here. You need WHERE [field[ Is Not Null as a
condition for each query.
There is no need for a WHERE clause to handle Nulls.
Null values will be ignored in the update.
Try it.
If you Trim() a Null, you get a Null. That means you'll be updating
the Nulls to Nulls, which is silly.
You'll be operating on more rows than necessary, which I think is a
bad idea. But, then, I have instincts developed from doing lots of
replication, where you don't want meaningless updates, which can
lead to unnecessary conflicts.
Even in non-replicated dbs, I wouldn't update a field to the same
value it started with.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
No Spam <no****@earthlink.net> wrote in
news:a5********************************@4ax.com: On 15 Nov 2005 14:18:06 -0800, "Wolf"
<sp*************@hotmail.com> wrote:
David W. Fenton wrote:
Meanwhile, Kevin has trimmed all the
fields in his table and probably won't be back to read this
thread.
No, I am back (and impressed!). Thank you very much!
Please remove my name from the attributions if you're not quoting
anything I wrote.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
David W. Fenton wrote:
So, you won't ever get any of my assistance again.
LMAO. Of course you're so full of yourself that it would never occur
to you that the world goes on even if "David W. Fenton, POS esq."
doesn't offer up any 'assistance', and that possibly YOU could learn
something new.
From what I've seen, your 'assistance' amounts to highjacking threads
in order to espouse you know a better way of doing something without
actually posting anything tangible of your own. Your 'assistance' is
more about building your "holier than thou", chest beating ego which
frankly I'd be happy to do without.
"Wolf" <sp*************@hotmail.com> schreef in bericht news:11**********************@g14g2000cwa.googlegr oups.com...
David W. Fenton wrote:
So, you won't ever get any of my assistance again.
LMAO. Of course you're so full of yourself that it would never occur
to you that the world goes on even if "David W. Fenton, POS esq."
doesn't offer up any 'assistance', and that possibly YOU could learn
something new.
David plonked me also a couple of weeks ago for hunting PCDataSheet's advertising as 'StopTheAdvertising'...
I did *not* like that, but indeed, life goes on. From what I've seen, your 'assistance' amounts to highjacking threads
in order to espouse you know a better way of doing something without
actually posting anything tangible of your own. Your 'assistance' is
more about building your "holier than thou", chest beating ego which
frankly I'd be happy to do without.
David sure knows what he is talking about. That's why I did not plonk *him* (yet).
But he has a *nasty* way of telling everybody that he is always right.
Arno R
LOL!
Oh, Lyle I haven't laughed like that for a long time.
Yeh, alright this is the new improved "give credit where credit's due" Terry
Kreft, but it's hard, very hard, to keep it up sometimes.
--
Terry Kreft
"lylefair" <ly***********@aim.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com... Who are you and what did you do with Terry Kreft?
Wolf <sp*************@hotmail.com> wrote:
: David W. Fenton wrote:
:>
:> So, you won't ever get any of my assistance again.
:>
: LMAO. Of course you're so full of yourself that it would never occur
: to you that the world goes on even if "David W. Fenton, POS esq."
: doesn't offer up any 'assistance', and that possibly YOU could learn
: something new.
:>From what I've seen, your 'assistance' amounts to highjacking threads
: in order to espouse you know a better way of doing something without
: actually posting anything tangible of your own. Your 'assistance' is
: more about building your "holier than thou", chest beating ego which
: frankly I'd be happy to do without.
I am relatively new to Access, and I've already benefited a lot
from David Fenton's posts, both in answer to questions that I
posted, and in reading his answers to other people's questions.
Thank you David Fenton, and thank you, all of you other amazing
helpers.
BTW, this newsgroup seems extremely forgiving and eager to help
without insult when compared with other technical newsgroups ...
--thelma
David W. Fenton wrote: So, you won't ever get any of my assistance again.
<PLONK>
Poor thing!
lylefair wrote: I respect those who post their code!
Sub Form_Current()
Me.Requery
End Sub
On 15 Nov 2005 11:37:45 -0800, "Wolf" <sp*************@hotmail.com>
wrote:
Drew? Is that you?
mike
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Todd_Calhoun |
last post by:
I'm trying to generate a random number, and then concetate it to a word to
create a password.
I get the number and assign it to a variable:
+++++++++++++++++++++++++++++
word = "dog"
...
|
by: Iain |
last post by:
I am attempting to run the folliwing update:
update rx set
startdate = date_sub(startdate, INTERVAL 14 DAY)
where rowid in
(
select rx.rowid
from rx, episode
where rx.rxbatch=0 and...
|
by: DB_2 |
last post by:
Greetings,
I was searching Google for ways to turn off transaction logging for
some queries. I came across this old post from Feb 2003:
> From: fareeda (fareeda@pspl.co.in)
> Subject: Re:...
|
by: Eric |
last post by:
I'm trying to reproduce the following table layout using CSS only and am
having some trouble with it. I'd like them to look identical but I'm having
trouble sizing the labels properly as it doesnt...
|
by: vissu |
last post by:
I am creating a application (timesheet) in centura 2.1 with table window with 64 columns (empno, empname, date1, comment1, date2, comment2, .......date31,comment31).
Normally when TAB key presses ...
|
by: GCM |
last post by:
Hi,
I have a table that has the following fields; LName, FName and MName. Also
there are other fields in the table. I need to create another table with
those fields combined as "Trim( & " " & &...
|
by: MLH |
last post by:
I'm sure its a bozo question, but it's got me stumped.
How do I search for a question mark in an open table
using CTRL-F to launch the search in the current field.
The field is a text field. Not...
|
by: Lokean |
last post by:
Sorry for this newbie question, this is not my realm of expertese.
I have searched google, tried several applications that claim they can do this, such as Mapforce, which I found confusing, to...
|
by: Parameswar Nayak |
last post by:
I have two same tables having same fields but table names are dirrerent.In a report I need all data from the two tables using a dataset in asingle table.So i can pass it to crystal report
|
by: Fuzz13 |
last post by:
I'm working on a Address book that has 4 fields: Name, Email, Phone, Birthday. I have so far been able to get the program to add a new entry in the csv when you click add (it currently does no sort...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
