|
Home > Archive > Programming with dBASE > March 2006 > modi stru
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]
|
|
| Ronald de Vries 2006-03-26, 8:23 pm |
| Modi stru does not work in the users appl. Just for the programmer.
I just think I could use an other field with alter tabel and make a new
field, removes the old field
make a new field and than the replace all command.
Is there another way in users environment? so I mean when the appl. is
started in exe?
| |
| Bruce Beacham 2006-03-27, 7:26 am |
| Ronald de Vries wrote:
> Modi stru does not work in the users appl. Just for the programmer.
> I just think I could use an other field with alter tabel and make a new
> field, removes the old field
> make a new field and than the replace all command.
> Is there another way in users environment? so I mean when the appl. is
> started in exe?
What are you trying to do? You cannot compile new code in the runtime.
But to edit something you could incorporate this in your peogram:
run (true, "notepad.exe")
Bruce Beacham
| |
| Ken Mayer [dBVIPS] 2006-03-27, 9:24 am |
| Ronald de Vries wrote:
> Modi stru does not work in the users appl. Just for the programmer.
> I just think I could use an other field with alter tabel and make a new
> field, removes the old field
> make a new field and than the replace all command.
> Is there another way in users environment? so I mean when the appl. is
> started in exe?
MODIFY STRUCTURE brings up the table designer, this is not supposed to
work in the runtime.
If you really want to try it, and you REALLY want to allow your users to
modify the table structure for your own application, I spent some time a
few years ago writing a table designer that is in the dUFLP ... I don't
recommend letting users change the structure of a table, though.
Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/
*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/dbase/dBASEBook.htm
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase
| |
| Ronald de Vries 2006-03-27, 8:24 pm |
| Thank you Ken,
Sometimes it is very handy as I developed an update in the software for 1
customer.
I tempory make available a form named "Tools"
Now 1 field was too small.
Then the user can make it from wide 30 to 60
I am standing by at the other side of the line.
You can use that tools.wfo just bij password "master"
So it was just for one customer in a special case and now we have not to
send the tables by mail which file is very large
(30.000 articles and ca. 90 fields)
Regards,
Ronald de Vries
>
> MODIFY STRUCTURE brings up the table designer, this is not supposed to
> work in the runtime.
>
> If you really want to try it, and you REALLY want to allow your users to
> modify the table structure for your own application, I spent some time a
> few years ago writing a table designer that is in the dUFLP ... I don't
> recommend letting users change the structure of a table, though.
>
> Ken
>
> --
> /(Opinions expressed are purely my own, not those of dataBased
> Intelligence, Inc.)/
>
> *Ken Mayer* [dBVIPS]
> /Golden Stag Productions/
> dBASE at goldenstag dot net
> http://www.goldenstag.net/dbase/dBASEBook.htm
> http://www.goldenstag.net/GSP
> http://www.goldenstag.net/dbase
| |
| Ken Mayer [dBVIPS] 2006-03-28, 9:24 am |
| Ronald de Vries wrote:
> Thank you Ken,
> Sometimes it is very handy as I developed an update in the software for 1
> customer.
> I tempory make available a form named "Tools"
> Now 1 field was too small.
> Then the user can make it from wide 30 to 60
> I am standing by at the other side of the line.
> You can use that tools.wfo just bij password "master"
> So it was just for one customer in a special case and now we have not to
> send the tables by mail which file is very large
> (30.000 articles and ca. 90 fields)
The other option is to have some code in the startup, check (using
TableDef()) to see if the field is the correct width, and if not, run
code that will do it ...
(alter table, add a temporary field, copy the data, drop the original
field, add the new field, I know, it's a bit of hassle, but ...)
Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/
*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/dbase/dBASEBook.htm
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase
| |
| Christian K 2006-03-28, 11:24 am |
| So there is no way to modify the type or width of an existing field,
you have to drop it, then add it & backfill the data?
...bummer..
Cheers,
Christian K.
Ken Mayer [dBVIPS] wrote:
> Ronald de Vries wrote:
>
> The other option is to have some code in the startup, check (using
> TableDef()) to see if the field is the correct width, and if not, run
> code that will do it ...
>
> (alter table, add a temporary field, copy the data, drop the original
> field, add the new field, I know, it's a bit of hassle, but ...)
>
> Ken
--
| |
| Ken Mayer [dBVIPS] 2006-03-28, 1:24 pm |
| Christian K wrote:
> So there is no way to modify the type or width of an existing field,
> you have to drop it, then add it & backfill the data?
>
> ..bummer..
Yeah. I believe that's a limitation of SQL, though, not dBASE.
Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/
*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/dbase/dBASEBook.htm
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase
| |
| Ivar B. Jessen 2006-03-28, 1:24 pm |
| On Tue, 28 Mar 2006 12:15:41 -0500, in dbase.programming,
Subject: Re: modi stru,
Message-ID: < xn0ek9ll31hmtnr000@n
ews.dbase.com>,
"Christian K" <ChristianK@HeroData.com> wrote:
>So there is no way to modify the type or width of an existing field,
>you have to drop it, then add it & backfill the data?
>
>..bummer..
Try the code below my signature. It takes the Fish table, modifies the width of
an existing field while retaining the data and then inserts the modified field,
including the data, in the now modified table :-)
The method is fine when the table only has a few columns. Ronald's table had
about 90 fields and you would have to name each individual field in the select
statement which would be tedious unless it was done programmatically. With 90
fields it is probably easier to use alter table as Ronald did.
Ivar B. Jessen
//-----
close tables
if file("Fish.dbf")
drop table Fish
endif
old_safety = set('safety')
set safety off
// Create a local Fish table to work with
copy table :dBasesamples:Fish to Fish
// Save the Name column to a char(80) wide column in a separate table
select cast(Name as char(80)) from fish save to "LongerName.dbf"
// Insert the 80 char wide column in a new table and save it to the name Fish
select f.ID, l.Name, f.Species, f."Length CM", f.Description, f."Fish Image" ;
from Fish f ;
inner join LongerName l ;
on ( f.Name = l.Name ) ;
save to "Fish.dbf"
// Clean up
drop table LongerName
set safety &old_safety.
// Display the result
use Fish
list ID, Name, Species
use
drop table Fish
//-----
| |
| Christian K 2006-03-28, 8:24 pm |
| Hmm, never thought of trying SQL join. Seems to be working well, except
when I try to create numerics. It seems that it always creates a double
field type. Example syntax:
select cast("length cm" as numeric(5,1)) from fish save to
"LongerName.dbf"
I also tried using decimal(x,y), with the same results.
Any ideas?
Much Thanks,
Christian K.
Ivar B. Jessen wrote:
> On Tue, 28 Mar 2006 12:15:41 -0500, in dbase.programming,
> Subject: Re: modi stru,
> Message-ID: < xn0ek9ll31hmtnr000@n
ews.dbase.com>,
> "Christian K" <ChristianK@HeroData.com> wrote:
>
>
> Try the code below my signature. It takes the Fish table, modifies
> the width of an existing field while retaining the data and then
> inserts the modified field, including the data, in the now modified
> table :-)
>
> The method is fine when the table only has a few columns. Ronald's
> table had about 90 fields and you would have to name each individual
> field in the select statement which would be tedious unless it was
> done programmatically. With 90 fields it is probably easier to use
> alter table as Ronald did.
>
> Ivar B. Jessen
>
> //-----
> close tables
> if file("Fish.dbf")
> drop table Fish
> endif
>
> old_safety = set('safety')
> set safety off
>
> // Create a local Fish table to work with
> copy table :dBasesamples:Fish to Fish
>
> // Save the Name column to a char(80) wide column in a separate table
> select cast(Name as char(80)) from fish save to "LongerName.dbf"
>
> // Insert the 80 char wide column in a new table and save it to the
> name Fish select f.ID, l.Name, f.Species, f."Length CM",
> f.Description, f."Fish Image" ; from Fish f ;
> inner join LongerName l ;
> on ( f.Name = l.Name ) ;
> save to "Fish.dbf"
>
> // Clean up
> drop table LongerName
> set safety &old_safety.
>
> // Display the result
> use Fish
> list ID, Name, Species
> use
>
> drop table Fish
> //-----
--
|
|
|
|
|