|
Home > Archive > dBASE Questions and Answers > September 2005 > copying contents
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Hi,
Using dBase III+, I want to copy some records from 1 database to
another. What is the best way to do it? I have an extensive dBase III+
manual with all commands, but no idea which command(s) I should use for
this.
Thank you,
Huub
| |
| Marilyn Price 2005-09-19, 7:23 am |
| In article <x#Vio#HvFHA.1044@news-server>, Huub <"h.v.niekerk at
hccnet.nl"> says...
> Hi,
>
> Using dBase III+, I want to copy some records from 1 database to
> another. What is the best way to do it? I have an extensive dBase III+
> manual with all commands, but no idea which command(s) I should use for
> this.
>
Hi, Huub,
Well, there's more than one way. It depends on whether you can easily
define what you want to copy to the second file and if the second file
exists or not.
If you can easily define what you want to copy and the destination
doesn't exist, then you can:
use firstfile
copy to secondfile for <some condition>
or
copy to secondfile while <some condition>
However, if the second file already exists, you could try something like
this:
use secondfile
append from firstfile for <some condition>
Unless your condition involves testing the deletion setting. Append
does not usually honor the deletion flag in dBase III+. If you want to
copy records to the second file and the records have already been
deleted in the first file, then you have to do something like this:
use firstfile
copy to tempfile for deleted() && or other condition
use secondfile
append from tempfile
erase tempfile
Hope this helps. If not, come on back and we'll refine this...
--
Marilyn Price
M. P. Data
| |
|
|
> Hi, Huub,
>
> Well, there's more than one way. It depends on whether you can easily
> define what you want to copy to the second file and if the second file
> exists or not.
>
> If you can easily define what you want to copy and the destination
> doesn't exist, then you can:
>
> use firstfile
> copy to secondfile for <some condition>
>
> or
>
> copy to secondfile while <some condition>
>
> However, if the second file already exists, you could try something like
> this:
>
> use secondfile
> append from firstfile for <some condition>
>
> Unless your condition involves testing the deletion setting. Append
> does not usually honor the deletion flag in dBase III+. If you want to
> copy records to the second file and the records have already been
> deleted in the first file, then you have to do something like this:
>
> use firstfile
> copy to tempfile for deleted() && or other condition
> use secondfile
> append from tempfile
> erase tempfile
>
> Hope this helps. If not, come on back and we'll refine this...
>
Hi Marylin.
Thank you for your answer. Searching the manual and looking at your
answer the best solution would be using the "copy to" command. Problem
is that the number of about 50 times .AND. causes exceeding the max.
line length. According to your answer I can use an append command.
Thinking about it: I could create a dBase script to do it all, right?
| |
| Mervyn Bick 2005-09-19, 9:23 am |
| On Mon, 19 Sep 2005 14:36:21 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
> Thank you for your answer. Searching the manual and looking at your
> answer the best solution would be using the "copy to" command. Problem
> is that the number of about 50 times .AND. causes exceeding the max.
> line length. According to your answer I can use an append command.
> Thinking about it: I could create a dBase script to do it all, right?
First things first. You are working with a copy of your original file
aren't you? Before you start trying to modify data you should always make
a security backup copy. If you haven't done so already, do it now. If it
all goes wrong you can wipe the slate clean and start again.
If this is a once off exercise then COPY TO is fine. COPY TO overwrites
the destination file with or without warning depending on whether SET
SAFETY is on or off. If this is an ongoing procedure then make sure you
use the intermediate temporary file that Marilyn suggested.
To answer your question, yes you could put everything into a little
program. (A program is limited to 5000 characters.) MODIFY COMMAND
COPYDATA (or whatever but make sure you avoid the reserved words when
naming files) Put all your instructions in and then Ctrl-W (or Ctrl-END)
to finish. DO COPYDATA to run the program.
Marilyn has got you pointed in the right direction for moving data from
one place to another but I'm wondering just what you need to do that has
50 .AND. operators in a FOR (or WHILE) condition. If you give us some
idea of what your file structure looks like (both files if they are not
the same) and what data you need to move we might be able to come up with
an easier way to do it.
Mervyn
--
The ns_ in my address is an attempt to thwart SPAM.
| |
|
|
> First things first. You are working with a copy of your original file
> aren't you? Before you start trying to modify data you should always
> make a security backup copy. If you haven't done so already, do it
> now. If it all goes wrong you can wipe the slate clean and start again.
>
Yes, it is backed up..
> If this is a once off exercise then COPY TO is fine. COPY TO
> overwrites the destination file with or without warning depending on
> whether SET SAFETY is on or off. If this is an ongoing procedure then
> make sure you use the intermediate temporary file that Marilyn suggested.
Once off indeed
>
> To answer your question, yes you could put everything into a little
> program. (A program is limited to 5000 characters.) MODIFY COMMAND
> COPYDATA (or whatever but make sure you avoid the reserved words when
> naming files) Put all your instructions in and then Ctrl-W (or
> Ctrl-END) to finish. DO COPYDATA to run the program.
Yes. It's been quite some time since I daily programmed in it.
>
> Marilyn has got you pointed in the right direction for moving data from
> one place to another but I'm wondering just what you need to do that
> has 50 .AND. operators in a FOR (or WHILE) condition. If you give us
> some idea of what your file structure looks like (both files if they
> are not the same) and what data you need to move we might be able to
> come up with an easier way to do it.
>
Situation: I have a database (obviously) and I need to print a large
number of records, but there are gaps between those records. So I
thought I'd better copy those records to a new database without gaps and
then print them without spilling paper. I hope this is clear enough.
> Mervyn
>
| |
| Mervyn Bick 2005-09-19, 9:23 am |
| On Mon, 19 Sep 2005 15:55:25 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
[color=darkred]
> Situation: I have a database (obviously) and I need to print a large
> number of records, but there are gaps between those records. So I
> thought I'd better copy those records to a new database without gaps and
> then print them without spilling paper. I hope this is clear enough.
Large is relative. <g> Roughly how many records in total and roughly how
many to extract? What criteria are you using to select the records to
copy? (Address, suburb, post-code, date, amount....) What causes the
gaps? Blank records, incomplete records, or whatever?
Mervyn
--
The ns_ in my address is an attempt to thwart SPAM.
| |
|
|
> Large is relative. <g> Roughly how many records in total and roughly
> how many to extract? What criteria are you using to select the records
> to copy? (Address, suburb, post-code, date, amount....) What causes
> the gaps? Blank records, incomplete records, or whatever?
>
> Mervyn
>
Ok, sorry..<g>. Oops...recount gives 158 records in total. The gaps are
records not to be copied. The only citreria being used is membership nr.
| |
| Mervyn Bick 2005-09-19, 11:23 am |
| On Mon, 19 Sep 2005 16:34:28 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
>
>
> Ok, sorry..<g>. Oops...recount gives 158 records in total. The gaps are
> records not to be copied. The only citreria being used is membership nr.
Okay, we're getting closer. <g> How do you know if a membership number is
to be copied? Paid up? Not paid? Junior member? Membership number
between x and y? Membership number not between x and y? Membership
number blank?
If all else fails, given that 158 records is not too many to deal with
manually, you could modify the structure of your original file and add a
logical field called, say, FORPRINT. Then use the BROWSE command (limit
the number of fields to display if necessary by specifying the fields you
need) and add a .T. to each record you want to move. COPY TO newfile FOR
FORPRINT will do the job. (Perhaps less input typing would be if you used
a 1 character wide Character field and input a T instead of .T. for the
records to print. In this case COPY TO newfile FOR FORPRINT ="T" or
COPY TO newfile FOR UPPER(FORPRINT)= "T" in case you got careless and use
t for some records instead of T <g> )
Mervyn.
--
The ns_ in my address is an attempt to thwart SPAM.
| |
| Marilyn Price 2005-09-20, 7:23 am |
| In article <jSJXEcRvFHA.304@news-server>, Huub <"h.v.niekerk at
hccnet.nl"> says...
>
> Thank you for your answer. Searching the manual and looking at your
> answer the best solution would be using the "copy to" command. Problem
> is that the number of about 50 times .AND. causes exceeding the max.
> line length. According to your answer I can use an append command.
> Thinking about it: I could create a dBase script to do it all, right?
>
That's a lot of conditions to have. I see Mervyn has stepped in also.
Could you give us a short example of just what you started out with
that's leading to 50 .and.s? Perhaps we can come up with something
shorter...
With 158 records, it may almost be easier to copy the whole table to a
new file, then delete the ones you don't want included in the report.
Just a thought.
--
Marilyn Price
M. P. Data
| |
|
| Marilyn Price wrote:
> In article <jSJXEcRvFHA.304@news-server>, Huub <"h.v.niekerk at
> hccnet.nl"> says...
>
>
>
> That's a lot of conditions to have. I see Mervyn has stepped in also.
>
> Could you give us a short example of just what you started out with
> that's leading to 50 .and.s? Perhaps we can come up with something
> shorter...
>
> With 158 records, it may almost be easier to copy the whole table to a
> new file, then delete the ones you don't want included in the report.
>
> Just a thought.
>
Hmm....but a handy thought at that. Working with a copy of the database
now, it sounds like a good idea. I would have to delete 750 records
then. Wonder what's easier.
| |
| Mervyn Bick 2005-09-20, 11:23 am |
| On Tue, 20 Sep 2005 16:09:33 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
>
> Hmm....but a handy thought at that. Working with a copy of the database
> now, it sounds like a good idea. I would have to delete 750 records
> then. Wonder what's easier.
I assumed that the 158 records you mentioned in a previous post was the
total file and not just the number to be copied. Still, even 750 records
to delete by hand is not too many to consider for a once off exercise.
(Nothing is impossible if you don't actually have to do it yourself! <G> )
Whether you add a field and mark the records to be deleted or simply
delete the unwanted records will be about the same amount of work. T and
down arrow as compared to Ctrl-U and down arrow.
It is still probably easiest to do a COPY TO if we can work out what the
FOR condition should be. How would you decide which membership numbers to
mark if you were going to follow the "add a field" route or how would you
decide to delete an unwanted record if you went that route? Either would
help us solve the problem. Is there some characteristic of the membership
number that influences the decision? Membership number between x and y?
Membership number not between x and y? Membership number blank? Subs not
paid? Members living in town? A combination of the above?
As Marilyn has said, could you also give us a short example, say the first
3 or 4 .AND.s (or more if you feel up to the typing but we really don't
need all 50. <g> ) of what you started with so that we could get a feel for
what you were trying to achieve.
Mervyn.
--
The ns_ in my address is an attempt to thwart SPAM.
| |
|
|
> I assumed that the 158 records you mentioned in a previous post was the
> total file and not just the number to be copied. Still, even 750
> records to delete by hand is not too many to consider for a once off
> exercise. (Nothing is impossible if you don't actually have to do it
> yourself! <G> )
Sorry, I should have been clearer about the number.
>
> Whether you add a field and mark the records to be deleted or simply
> delete the unwanted records will be about the same amount of work. T
> and down arrow as compared to Ctrl-U and down arrow.
>
> It is still probably easiest to do a COPY TO if we can work out what
> the FOR condition should be. How would you decide which membership
> numbers to mark if you were going to follow the "add a field" route or
> how would you decide to delete an unwanted record if you went that
> route? Either would help us solve the problem. Is there some
> characteristic of the membership number that influences the decision?
> Membership number between x and y? Membership number not between x and
> y? Membership number blank? Subs not paid? Members living in town? A
> combination of the above?
Unfortunately, I've only been given a list with the records to be
printed. Although the record numbers are ascending, there's no way to
distinguish them from the other records other than add a field and mark
them accordingly, I'm afraid.
>
> As Marilyn has said, could you also give us a short example, say the
> first 3 or 4 .AND.s (or more if you feel up to the typing but we
> really don't need all 50. <g> ) of what you started with so that we
> could get a feel for what you were trying to achieve.
>
What I tried so far is this:
copy to herr5.dbf <all fields> for lidno = '105' .and. lidno = '112'
..and. lidno = '139' .and. (so on)
| |
| Mervyn Bick 2005-09-20, 8:24 pm |
| On Tue, 20 Sep 2005 19:12:58 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
> Unfortunately, I've only been given a list with the records to be
> printed. Although the record numbers are ascending, there's no way to
> distinguish them from the other records other than add a field and mark
> them accordingly, I'm afraid.
>
> What I tried so far is this:
>
> copy to herr5.dbf <all fields> for lidno = '105' .and. lidno = '112'
> .and. lidno = '139' .and. (so on)
Ah. Now the problem becomes clear.
Set up a file, say keepmemb with one field, say, memberno. Input the
numbers from your list. (When I have had to do this sort of thing in the
past I found it easier to input the numbers into a spreadsheet and then
export the data as a .CSV file which could then be imported into a .DBF
file. Given that there are only 158 numbers in this case it is probably
just as easy to input them straight into the .DBF file using APPEND. Once
you are done you can use BROWSE to check for any errors and correct as
necessary.)
Create a little program called, say, movememb (Feel free to cut and paste)
SELECT A
USE orgfile INDEX ON lidno TO lidno
COPY STRUCTURE TO newfile
SELECT B
USE newfile
SELECT C
USE keepmemb
DO WHILE .NOT. EOF()
cMlidno = memberno
SELECT A
SEEK cMlidno
IF FOUND()
SELECT B
APPEND BLANK
REPLACE B->lidno WITH A->lidno, B->field2 WITH A->field2,;
B->field3 WITH A->field3
* Use the correct field names and be sure to do all of them
ENDIF
SELECT C
IF .NOT. EOF()
SKIP
ENDIF
ENDDO
CLOSE ALL
DO movememb and Bob's your uncle! And it has to be easier than deleting
750 records. <g> (At least I hope so. All this is untested as I have not
used dBase III+ for nearly 20 years.)
Mervyn.
--
The ns_ in my address is an attempt to thwart SPAM.
| |
| Mervyn Bick 2005-09-21, 3:24 am |
| On Tue, 20 Sep 2005 19:12:58 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
> What I tried so far is this:
>
> copy to herr5.dbf <all fields> for lidno = '105' .and. lidno = '112'
> .and. lidno = '139' .and. (so on)
I must have been asleep when I wrote the previous post because I should
have pointed this out before I gave you the code to sort things out. As
Marilyn and I said in earlier posts having 50 or so .AND.s in a FOR
condition would be most unlikely. 50 .OR.s would also be unlikely but
would not ring the same alarm bells as it could just be possible. One
would, however, not usually do things that way where one is looking for
more than just a few matching records.
The .AND.s in your FOR condition should be .OR.s. The FOR condition in a
COPY looks at each row one at a time. In other words there is only one
lidno in a record so it can't possibly have 2 values such as 105 AND 110.
But if lidno is 105 OR 110 then the test would be true if the record held
either of the numbers. So, both the record for lidno 105 and the record
for 110 would be copied but the records for 106, 107, 108 and 109 would
not.
One would use .AND. if one was looking at more than one field in each
record at the same time. Say if paid = .T. .AND. city = "Johannesburg".
This would only copy the paid members from Johannesburg and would skip
unpaid members in Johannesburg as well as paid and unpaid members living
elsewhere.
In my previous post I said "cut and paste" but I don't think you can paste
directly into a DOS based program even if it is running under Windows.
The way round this would be to cut and paste into Notepad and save as
movememb.prg. Then from within dBase you can MODIFY COMMAND (or MODI COMM
if you're lazy <g> ) movememb to edit the file and field names.
Mervyn
--
The ns_ in my address is an attempt to thwart SPAM.
| |
| Marilyn Price 2005-09-21, 7:23 am |
| Excellent suggestion. Minor correction below.
Also, good catch on the .and.s and .or.s
In article <op. sxe3f81ih8j4jw@mervy
n>, ns_mervynb@telkomsa.net says...
>
> SELECT A
> USE orgfile
INDEX ON lidno TO lidno && this needs to be on its own line
> COPY STRUCTURE TO newfile
> SELECT B
> USE newfile
> SELECT C
> USE keepmemb
> DO WHILE .NOT. EOF()
> cMlidno = memberno
> SELECT A
> SEEK cMlidno
> IF FOUND()
> SELECT B
> APPEND BLANK
> REPLACE B->lidno WITH A->lidno, B->field2 WITH A->field2,;
> B->field3 WITH A->field3
> * Use the correct field names and be sure to do all of them
* also, you can use multiple replace commands, if it doesn't all fit on
* one line.
> ENDIF
> SELECT C
* The test for eof() here is not really necessary, but the skip is
> IF .NOT. EOF()
> SKIP
> ENDIF
> ENDDO
> CLOSE ALL
>
--
Marilyn Price
M. P. Data
| |
| Mervyn Bick 2005-09-21, 9:24 am |
| On Wed, 21 Sep 2005 13:54:25 +0200, Marilyn Price <mprice@tri_con.net>
wrote:
> Excellent suggestion. Minor correction below.
>
> Also, good catch on the .and.s and .or.s
It was a lesson learnt the hard way in days of yore. <g>
> INDEX ON lidno TO lidno && this needs to be on its own line
Of course. That's the rust in the old brain showing. I haven't used
dBase DML in anger for ages.
> * also, you can use multiple replace commands, if it doesn't all fit on
> * one line.
You're right. I should have mentioned that as I don't know just how many
fields Huub is dealing with. It's a pity that AUTOMEM is not available in
dBase III+ as it would have made things that much easier.
[color=darkred]
> * The test for eof() here is not really necessary, but the skip is
>
This is almost a conditioned reflex a la Pavlov. It was something I
learned to do almost 30 years ago when I started programming in Cobol.
For all I know now, it may not even have been necessary then but that's
the way I started out and now the test for end-of-file "just happens"
before I move on to a new record. <g> It really is "belt and braces" and
quite unnecessary here as you point out. On the other hand, it's not
doing any harm either.
Mervyn
--
The ns_ in my address is an attempt to thwart SPAM.
| |
|
| Mervyn Bick wrote:
> On Wed, 21 Sep 2005 13:54:25 +0200, Marilyn Price <mprice@tri_con.net>
> wrote:
>
>
>
> It was a lesson learnt the hard way in days of yore. <g>
>
>
>
> Of course. That's the rust in the old brain showing. I haven't used
> dBase DML in anger for ages.
>
>
>
> You're right. I should have mentioned that as I don't know just how
> many fields Huub is dealing with. It's a pity that AUTOMEM is not
> available in dBase III+ as it would have made things that much easier.
>
>
>
> This is almost a conditioned reflex a la Pavlov. It was something I
> learned to do almost 30 years ago when I started programming in Cobol.
> For all I know now, it may not even have been necessary then but that's
> the way I started out and now the test for end-of-file "just happens"
> before I move on to a new record. <g> It really is "belt and braces"
> and quite unnecessary here as you point out. On the other hand, it's
> not doing any harm either.
>
> Mervyn
>
Thank you both very much. I'll try very soon and let you know the result.
| |
| Marilyn Price 2005-09-23, 7:23 am |
| In article <op. sxgeb2feh8j4jw@mervy
n>, ns_mervynb@telkomsa.net says...
>
> This is almost a conditioned reflex a la Pavlov. It was something I
> learned to do almost 30 years ago when I started programming in Cobol.
> For all I know now, it may not even have been necessary then but that's
> the way I started out and now the test for end-of-file "just happens"
> before I move on to a new record. <g> It really is "belt and braces" and
> quite unnecessary here as you point out. On the other hand, it's not
> doing any harm either.
>
Absolutely correct. I've done many belt and suspenders type code
segments in my career <g>.
--
Marilyn Price
M. P. Data
| |
| Mervyn Bick 2005-09-23, 9:23 am |
| On Fri, 23 Sep 2005 14:02:57 +0200, Marilyn Price <mprice@tri_con.net>
wrote:
> Absolutely correct. I've done many belt and suspenders type code
> segments in my career <g>.
The IF FOUND() test is also probably not really necessary in this case as
we can assume that the records to be copied are, in fact, a sub-set of the
original records and all records in the control file WILL be found.
Still, it's a good idea to have an IF FOUND() after any SEEK as a general
rule. (Which is why it's there. <g> ) Strictly speaking there should also
be an ELSE in there with code to deal with any "not founds". (That's not
there because I was lazy!)
Mervyn
| |
|
| Ok, have tested and get the following:
.. do movememb.prg
lidno.ndx already exists, overwrite? (Y/N) Y
100% indexed 803 record indexed
File already open
Called from - C:movememb.prg
Cancel, Ignore or Delay? (C, I, of D)
(sorry, translating messages from Dutch) Any idea? Thank you.
| |
| Mervyn Bick 2005-09-24, 11:23 am |
| On Sat, 24 Sep 2005 15:22:01 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
> Ok, have tested and get the following:
>
> . do movememb.prg
> lidno.ndx already exists, overwrite? (Y/N) Y
> 100% indexed 803 record indexed
> File already open
> Called from - C:movememb.prg
> Cancel, Ignore or Delay? (C, I, of D)
>
> (sorry, translating messages from Dutch) Any idea? Thank you.
It looks as if either newfile (or whatever you have called it) or keepmemb
is open.
Try putting CLOSE ALL DATABASE as the first line of the program.
If this dosn't work put
SET ECHO ON
SET STEP ON at the top of the file and step through untill you get the
error.
If you put SET SAFETY OFF at the top of the file you wont get the warning
messages about the index or newfile existing and they will simply be
overwrittten.
Mervyn
| |
| Mervyn Bick 2005-09-24, 11:23 am |
| On Sat, 24 Sep 2005 16:41:54 +0200, Mervyn Bick <invalid@invalid.invalid>
wrote:
> If you put SET SAFETY OFF at the top of the file you wont get the
> warning messages about the index or newfile existing and they will
> simply be overwrittten.
Remember to SET SAFETY ON again at the end of the program as if it stays
off you might overwrite something else without warning when you are
working from the dot prompt.
Mervyn
| |
|
| Mervyn Bick wrote:
> On Sat, 24 Sep 2005 16:41:54 +0200, Mervyn Bick
> <invalid@invalid.invalid> wrote:
>
>
>
>
> Remember to SET SAFETY ON again at the end of the program as if it
> stays off you might overwrite something else without warning when you
> are working from the dot prompt.
>
> Mervyn
Now I get the message that the datatype of cMlidno is not correct. Any idea?
| |
| Mervyn Bick 2005-09-24, 1:23 pm |
| On Sat, 24 Sep 2005 18:51:17 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
> Now I get the message that the datatype of cMlidno is not correct. Any
> idea?
At least we've got a little bit further. <g> That will be coming from the
SEEK command. SEEK only works on character data.
I assumed that lidno was a character type field but it looks as if I was
wrong. Or perhaps memberno in keepmemb is not the same type as lidno.
Make sure they are the same. Don't change your main data file (just as a
general principal because there may be other programs that use the table)
but you can MODIFY STRUCTURE keepmemb to make it the same as the main file.
If the two fields are now character type then the program should work
without further changes.
If they are both numeric you should change the INDEX line to INDEX ON
STR(lidno,x,y) TO lidno where x and y are the length and number of
decimals in the field description for lidno.
Change cMlidno to nMlidno (It isn't really necessary but when naming
variable in this fashion the first character denotes the type and the M
denotes Memory. This helps one keep track of things but dBase doesn't mind
what you call variables.)
Change the SEEK to SEEK STR(nMlidno,x,y) and it all should work.
Mervyn
| |
|
| Mervyn Bick wrote:
> On Sat, 24 Sep 2005 18:51:17 +0200, Huub <"h.v.niekerk at hccnet.nl">
> wrote:
>
>
>
>
> At least we've got a little bit further. <g> That will be coming from
> the SEEK command. SEEK only works on character data.
>
> I assumed that lidno was a character type field but it looks as if I
> was wrong. Or perhaps memberno in keepmemb is not the same type as
> lidno. Make sure they are the same. Don't change your main data file
> (just as a general principal because there may be other programs that
> use the table) but you can MODIFY STRUCTURE keepmemb to make it the
> same as the main file.
>
> If the two fields are now character type then the program should work
> without further changes.
>
> If they are both numeric you should change the INDEX line to INDEX ON
> STR(lidno,x,y) TO lidno where x and y are the length and number of
> decimals in the field description for lidno.
>
> Change cMlidno to nMlidno (It isn't really necessary but when naming
> variable in this fashion the first character denotes the type and the M
> denotes Memory. This helps one keep track of things but dBase doesn't
> mind what you call variables.)
>
> Change the SEEK to SEEK STR(nMlidno,x,y) and it all should work.
>
> Mervyn
I changed the type of memberno, so that's ok now. Now I keep getting the
message that a field doesn't exist. Are fieldnames by any chance
case-sensitive?
| |
| Mervyn Bick 2005-09-25, 3:23 am |
| On Sun, 25 Sep 2005 08:39:17 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
> I changed the type of memberno, so that's ok now. Now I keep getting the
> message that a field doesn't exist. Are fieldnames by any chance
> case-sensitive?
dBase is completely case insensitive except where you are comparing two
strings. In that case if the case is not important one would compare
UPPER(string a) with UPPER(string b).
It sounds like a spelling mistake if the program can't find a field. Check
the field names in the REPLACE statement carefully.
Mervyn
| |
|
|
> dBase is completely case insensitive except where you are comparing two
> strings. In that case if the case is not important one would compare
> UPPER(string a) with UPPER(string b).
>
> It sounds like a spelling mistake if the program can't find a field.
> Check the field names in the REPLACE statement carefully.
>
> Mervyn
Another problem: at the second 'replace' it puts a question-mark above
the first '->' and says that the variable is not found. What does that mean?
| |
| Mervyn Bick 2005-09-25, 9:23 am |
| On Sun, 25 Sep 2005 14:20:27 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
> Another problem: at the second 'replace' it puts a question-mark above
> the first '->' and says that the variable is not found. What does that
> mean?
Just what it says. <g> For some reason it can't find the variable.
Again, make sure the spelling matches the spelling in the table both for
the B-> and the A->. Make sure there is no , or ; at the end of the first
REPLACE.
From the dot prompt CLOSE ALL and then USE your newfile. LIST ALL will
show you the first (only) record with data in some of the fields. The
first field that is empty is the one that the program is choking on.
I am going out for a while now but I will look in later in case you still
have problems.
Mervyn
| |
|
| Mervyn Bick wrote:
> On Sun, 25 Sep 2005 14:20:27 +0200, Huub <"h.v.niekerk at hccnet.nl">
> wrote:
>
>
>
>
>
> Just what it says. <g> For some reason it can't find the variable.
> Again, make sure the spelling matches the spelling in the table both
> for the B-> and the A->. Make sure there is no , or ; at the end of
> the first REPLACE.
>
> From the dot prompt CLOSE ALL and then USE your newfile. LIST ALL
> will show you the first (only) record with data in some of the fields.
> The first field that is empty is the one that the program is choking on.
>
> I am going out for a while now but I will look in later in case you
> still have problems.
>
> Mervyn
>
Somehow I don't get it. A variable name is a fieldname, right? I
double-checked the fieldnames of both the original and the new database.
Nothing is wrong. When I look into the data of the newly created
database, only the 1st field (lidno) is filled. The 2nd field is empty,
while the error happens on the 3rd field. Also, as I stated before, the
arrow indicating the error points at the 1st '->'. Not at 'B', nor at
the fieldname.
| |
| Mervyn Bick 2005-09-25, 8:23 pm |
| On Sun, 25 Sep 2005 20:49:35 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
> Somehow I don't get it. A variable name is a fieldname, right?
Right.
> I double-checked the fieldnames of both the original and the new
> database. Nothing is wrong. When I look into the data of the newly
> created database, only the 1st field (lidno) is filled. The 2nd field is
> empty, while the error happens on the 3rd field. Also, as I stated
> before, the arrow indicating the error points at the 1st '->'. Not at
> 'B', nor at the fieldname.
The field names in the new table will be identical to those in the old
table as the structure is a copy of the original. The important thing is
to make sure that the field names are correct in the REPLACE statement.
The arrow indicating the error can be misleading at time. It is supposed
to indicate the error but can sometimes be misplaced. Check that the
REPLACE statement is in the form REPLACE B-> fieldname WITH A->fieldname
(no spaces in the x->fieldname piece) followed by a comma before the next
B WITH A fieldnames and so on. If you are going to wrap the line do it
after the comma of a fieldname pair and end the line with ; On the next
line carry on with fieldname pairs. The last continuation line ends with
an a->fieldname with no comma or ;. If there are many fieldnames you can
use a second )or even more) REPLACE statement for the next group of
fieldnames.
If this doesn't help do the following at the dot prompt
SET ALTERNATE TO temp.txt
SET ALTERNATE ON
USE <original file>
LIST STRUCTURE
USE keepmemb
LIST STRU
SET ALTERNATE OFF
CLOSE ALL
Cut and paste the contents of temp.txt and your program into a message and
let's have a look.
Mervyn
| |
| Mervyn Bick 2005-09-25, 8:23 pm |
| On Sun, 25 Sep 2005 22:07:06 +0200, Mervyn Bick <invalid@invalid.invalid>
wrote:
> Check that the REPLACE statement is in the form REPLACE B-> fieldname
> WITH A->fieldname (no spaces in the x->fieldname piece) followed by a
> comma before the next B WITH A fieldnames and so on.
And then I promptly put a space between B-> and fieldname! That whole bit
was confusing enough without adding typos. Sorry about that.
Mervyn
| |
| Marilyn Price 2005-09-26, 7:23 am |
| In article <CJEHoIgwFHA.2096@news-server>, Huub <"h.v.niekerk at
hccnet.nl"> says...
>
> Nothing is wrong. When I look into the data of the newly created
> database, only the 1st field (lidno) is filled. The 2nd field is empty,
> while the error happens on the 3rd field. Also, as I stated before, the
> arrow indicating the error points at the 1st '->'. Not at 'B', nor at
> the fieldname.
>
Also, Huub, could you copy and paste the replace statement into a
message here? Perhaps we can spot something there.
Try one other thing first. I think the replace a->field with b->field
construct first appeared in dBase IV. See if changing the replace
command to look like this instead:
REPLACE fieldname with b->fieldname, nextfield with b->nextfield
Did that make a difference?
--
Marilyn Price
M. P. Data
| |
| Mervyn Bick 2005-09-26, 7:23 am |
| On Mon, 26 Sep 2005 13:43:03 +0200, Marilyn Price <mprice@tri_con.net>
wrote:
> Also, Huub, could you copy and paste the replace statement into a
> message here? Perhaps we can spot something there.
>
> Try one other thing first. I think the replace a->field with b->field
> construct first appeared in dBase IV. See if changing the replace
> command to look like this instead:
>
> REPLACE fieldname with b->fieldname, nextfield with b->nextfield
If Huub stuck to the original code I posted, workarea B holds the file to
be appended to so the REPLACE would be
REPLACE fieldname WITH a->fieldname, nextfield WITH a->nextfield
Mervyn
| |
|
| Marilyn Price wrote:
> In article <CJEHoIgwFHA.2096@news-server>, Huub <"h.v.niekerk at
> hccnet.nl"> says...
>
>
>
> Also, Huub, could you copy and paste the replace statement into a
> message here? Perhaps we can spot something there.
>
> Try one other thing first. I think the replace a->field with b->field
> construct first appeared in dBase IV. See if changing the replace
> command to look like this instead:
>
> REPLACE fieldname with b->fieldname, nextfield with b->nextfield
>
> Did that make a difference?
>
Odd thing I notice now is that it first says that 1 record has been
replaced. On your suggestion: the same error on the same place occurs again.
| |
| Mervyn Bick 2005-09-26, 9:23 am |
| On Mon, 26 Sep 2005 14:17:23 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
> Odd thing I notice now is that it first says that 1 record has been
> replaced. On your suggestion: the same error on the same place occurs
> again.
Okay. Now we need to see your program and the structure of the original
file. The SEEK is working so we dont really need to see the structure of
the control file (keepmemb).
Mervyn
| |
|
| > Okay. Now we need to see your program and the structure of the original
> file. The SEEK is working so we dont really need to see the structure
> of the control file (keepmemb).
>
> Mervyn
Movememb.prg and the structure of the files. I hope this clears up some
things. After this is solved, I consider moving the database to MySQL.
The system on which dBase is running is only 120MHz running W95...
| |
| Mervyn Bick 2005-09-26, 9:23 am |
| On Mon, 26 Sep 2005 14:53:43 +0200, Huub <"h.v.niekerk at hccnet.nl">
wrote:
>
> Movememb.prg and the structure of the files. I hope this clears up some
> things. After this is solved, I consider moving the database to MySQL.
> The system on which dBase is running is only 120MHz running W95...
if found()
select B
append blank
replace lidno with A->lidno
replace naam with A->naam˙ && Error
replace voorvoeg with A->voorvoeg
replace B->voorl with A->voorl
replace B->straat with A->straat
replace B->huisnr with A->huisnr ˙ && Error
replace B->postcode with A->postcode
replace B->plaats with A->plaats˙ && Error
replace B->bez with A->bez
replace B->datum with A->datum
replace B->lidnr with A->lidnr
replace B->code with A->code
replace B->code2 with A->code2
replace B->code3 with A->code3
endif
Here we go! Spelling it was. <g> Opening the file in Notepad showed the
"funnies' straight away. These characters may not be showing on your
screen but the 2nd, 6th and 8th replaces have somehow managed to get a y
with a diaeresis ( two little dots above the letter, umlaut in German,
deelteken in Afrikaans) at the end of the line.
Erase these extra characters (you may need to delete the lines and retype
them if the y doesn't show on your screen) and all should be well.
You might like to add the following between the last replace and the endif.
else
? cMlido
This will give you an indication if any entry in keepmenb doesn't find a
match in lidno04.
Mervyn
| |
|
| > Here we go! Spelling it was. <g> Opening the file in Notepad showed
> the "funnies' straight away. These characters may not be showing on
> your screen but the 2nd, 6th and 8th replaces have somehow managed to
> get a y with a diaeresis ( two little dots above the letter, umlaut in
> German, deelteken in Afrikaans) at the end of the line.
>
Now why didn't I think of that possibilty....btw, it's called trema in
Dutch if it's on a letter where it's normally not, like on an 'a', 'e',
'i', 'o' or 'u'.
> Erase these extra characters (you may need to delete the lines and
> retype them if the y doesn't show on your screen) and all should be well.
>
All looks well now. Thank you both very much for your help.
| |
| Marilyn Price 2005-09-27, 7:24 am |
| In article <op. sxpk8fmk380wm4@mervy
n>, invalid@invalid.invalid says...
>
> If Huub stuck to the original code I posted, workarea B holds the file to
> be appended to so the REPLACE would be
>
> REPLACE fieldname WITH a->fieldname, nextfield WITH a->nextfield
>
That's what I get for going by memory :(
--
Marilyn Price
M. P. Data
| |
| Marilyn Price 2005-09-27, 7:24 am |
| In article <MhCjncqwFHA.2096@news-server>, Huub <"h.v.niekerk at
hccnet.nl"> says...
>
> All looks well now. Thank you both very much for your help.
>
And thanks for hanging in there! Glad you've got it working.
--
Marilyn Price
M. P. Data
|
|
|
|
|