Problems after moving files to other working directory
Stephen Ford
In a display of mad enthusiasm some time ago, I moved files from one folder
to another in an attempt to access all the related databases from the same
working directory.
Of course, it all stopped working. It was a long time ago, so I can't
provide specifics. I restored backups and such like, and all returned to
normal ...
I was considered repeating the attempt. What sort of considerations do I
have to take into account to make this a trouble- and stress-free operation?
The databases are just single table afairs. One has two linked tables in one
form. There are a couple of scripts here and there.
Regards
Stephen Ford
Surrey, UK
Jim Giner
You don't say "what" stopped working, but can I venture a guess that you
don't use aliases on your table names in your opal? One should always use
an alias for every 'external' object you access/open. That includes forms
that you call, tables you open, scripts you execute, libraries that you
open. Need I say more?
Of course if you are an alias user (that sounds weird), then maybe you can
elaborate on what went wrong the last time.
"Stephen Ford" <stephen_fo...@ntlworld.com> wrote in message
news:412c617e$1_3@cnews...
Stephen Ford
Jim
> You don't say "what" stopped working, but can I venture a guess that you
> don't use aliases on your table names in your opal? One should always use
> an alias for every 'external' object you access/open. That includes forms
> that you call, tables you open, scripts you execute, libraries that you
> open. Need I say more?
>
> Of course if you are an alias user (that sounds weird), then maybe you can
> elaborate on what went wrong the last time.
Sorry to be so vague. Yes, I think is was to do with things not being found.
You might guess from my terminology that I'm very much the novice user. I
seem to remember figuring out that tables and forms could not find each
other, but I could not figure out how to change whatever seemed to need
changing on the fly.
Let's say that I want to modify a single form that relates to a single
table. There are a couple of scripts called by buttons on the form. What
modifiaction strategy do I need to apply to the table, form and scripts to
enable me to bodily move the database to another folder?
Regards
Stephen
Jim Giner
> Let's say that I want to modify a single form that relates to a single
> table. There are a couple of scripts called by buttons on the form. What
> modifiaction strategy do I need to apply to the table, form and scripts to
> enable me to bodily move the database to another folder?
>
> Regards
> Stephen
Stephen,
In your form's data model - be sure to first select an alias from the
dropdown box on that page before selecting the tables themselves. (after
placing a table in your model, click on it and make sure you see the table
name along with an alias (:myalias:tablename) at the top of the screen.)
Right now - I'm guessing that if you go into the data model and click on the
existing tables, you won't see an alias in front of the name.
In any code you write - always specify the alias name. For example to open a
form called MYFORM1, you should do the following:
var
f form
endvar
if not f.open(":MYALIAS:MYFORM1") then
(handle error)
endif
Again - you probably coded up something like this:
f.open("MYFORM1")
The reason this worked before is because Pdox defaults to the :work: alias
when none is specified, and the :work: alias points to the current folder
where you probably had everything stored until you decided to do some
housecleaning.
Personally, I set up all of my appls with three folders and three aliases:
one for the source programs, one for the delivered programs, and one for the
tables. Something like this:
:appl: -delivered forms, etc.
:appls: - source forms, etc.
:appld: - tables
Naturally, I don't use the :appls: alias in my logic very often (only when
I'm debugging and don't want to run a delivered form right then). But it
makes it easy to switch to the right folder when I'm doing development
work.
Tony McGuire
Jim has you on your way.
To test that this is the issue, you can copy your files to a new directory.
Then when you start Paradox, go to File | Working Directory and choose that
new directory. Now try to run your files and see if things work.
If so, then Jim's assumption is correct (and the same as I would think is
the issue) and just setting aliases will likely make your application
portable to different directories with a simple alias change.
I offer this as a simple way to test that setting up an alias is the only
issue.
--
--
Paradox Support http://www.thedbcommunity.com/support/
Tony McGuire
_____________
Dennis Santoro
Jim has you started. But you should also not be using the working directory as
you are. WORK should just be a location for odds and ends and temporary stuff
since it is too mobile. I strongly suggest you check out my paper on Database
basics on our Paradox resources page (link in my signature). There are
discussions of using aliases, not using WORK, how to fix that if you started
with WORK or no aliases at all and things on many other common pitfalls and best
practices.
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
Offices in the United States and Germany
Providing solutions to health care, business, governments and non-profits since
1982
Stephen Ford
Jim
> In your form's data model - be sure to first select an alias from the
> dropdown box on that page before selecting the tables themselves. (after
> placing a table in your model, click on it and make sure you see the table
> name along with an alias (:myalias:tablename) at the top of the screen.)
> Right now - I'm guessing that if you go into the data model and click on
the
> existing tables, you won't see an alias in front of the name.
There wasn't a data model for this form, so I've created a new one. There is
only one table. The name in the table window only shows its name - no alias.
After creating an alias ("filing"), and adding the same table again, the
name in the table window still only shows its name.
Process
--------
File > Open > Data Model > {select the data model file}
{Data Model Designer: Filf01.dm; Shows the Filing.db table.}
{right click} Add > Object
{select} alias=filing
{select} file=filing.db
{window opens with "FIling.db" in the title bar}
{I was expecting :filing:filing.db}
Should I see ":filing:filing.db" in the table window title bar, or some
other titlebar?
> Again - you probably coded up something like this:
> f.open("MYFORM1")
itemTC.open("filing.db")
Stephen
Stephen Ford
Dennis
<...But you should also not be using the working directory ...>>
Hmmm, that's starting to become all too clear. :-{
<...I strongly suggest you check out my paper on Database
> basics ...>
I'll check it out.
Thanks
Stephen
Dennis Santoro
In P9 you won't see the alias for the master table directly in the data model.
If you right click on the MRO or Table frame on the form itself and select
object explorer you will find if you are using the alias in the Properties tab
in the TableName properties.
But if you had a form with any table objects on it you HAD a data model. So I'm
not sure what you mean by the form had no data model. Did it not have any table
objects on it (nor even any bare fields which is a really bad idea but still
gives you a data model). You don't need a saved dm file though. That is not
directly relevant to your form. Only the one you get when you select a form in
design mode and then go Format| Data model or when you click through to that
from the define table or define field dialogs. So the way you are going to the
data model does not get you the one the form is using (which is embedded in the
form, not a stand alone file).
Your last line of code appears to be opening a tcursor to the table, not a form.
Also, it will only work if filing is in the WORK alias which is not what you
want.
Steve Caple
Stephen Ford wrote:
> There wasn't a data model for this form, so I've created a new one.
There is ALWAYS a data model if you have any tables in it. That doesn't
mean there's a one of .dm files that are created if you "save" in the data
model dialog; and in my opinion those are just about worthless. Go to the
form, choose main menu Format/Data Model, and what do you see?
--
Steve Caple
SeatTech
Jim Giner
Every form that uses a table has a data model. Don't confuse the separate
construct that Paradox calls a Data Model with what we're discussing here.
Pdox allows you to 'design' and store a Data Model for a complex database
that you may want to use in multiple places. That way you dont' have to
'build' it each time you start a new form - you can just point to the .DM
file and you get it automatically. Even there though, you want to be sure
to create THAT data model with aliases or you'll really have troubles when
you start using it all over the place.
My references for detecting if you used an alias were for an older version
of Pdox - in P9 once you have placed a table into your data model (Format,
Data Model) you can check if the alias has been assigned by right clicking
on a table in the data model (the right pane) and selecting Filter. This
will pop up a dialog box that will show the tables in your model so far and
it will show the aliases in front of each table in use if you have used
aliases.
You click on the dropdown of aliases that is in the left pane right above
the current folder's contents to select the alias you want. If you don't
select an alias, then when you look at the Filter conditions, you will only
see the table names without alias names in front of them.
Hope this all makes sense. It's really a simple thing to do once you are
used to doing it.
And to finish - your last example :
>
> itemTC.open("filing.db")
>
you should have an alias in front of the "filing.db" name. Always use an
alias when you are opening something external to your current file (form,
script, library) so that the system knows where to look for it.
Tony McGuire
: Every form that uses a table has a data model.
I know what you mean (I think), but take Stephen's example.
If the form opens a table and gets data, then opens other tables and
adds/inserts/changes data, this could all be done with tcursors - and no
data model is needed.
So, while I agree with what you mean (I think), I have to disagree with the
bare statement.
"Every form on which is placed a table object (MRO/TF) and/or [bare] field
has a data model" is closer, I think.
Stephen Ford
Steve
> There is ALWAYS a data model if you have any tables in it. That doesn't
> mean there's a one of .dm files that are created if you "save" in the data
> model dialog; and in my opinion those are just about worthless. Go to the
> form, choose main menu Format/Data Model, and what do you see?
I meant there wasn't a "saved" data model. My post above yours still
applies.
HTH
Stephen
Stephen Ford
Dennis
> If you right click on the MRO or Table frame on the form itself and select
> object explorer you will find if you are using the alias in the Properties
tab
> in the TableName properties.
I did this on the form, selected properties, selected a field and saw
"TableName" and the value was :WORK:FILING.DB
It looked as though I could edit WORK. I have a "filing" alias now. Can I
change work to filing without it all going pear-shaped?
> But if you had a form with any table objects on it you HAD a data model.
So I'm
> not sure what you mean by the form had no data model.
After reading the other posts it seems that I mistook Format > Data Model
for the data model that everyone else is talking about. I thought they where
one and the same. Apparently not.
> Your last line of code appears to be opening a tcursor to the table, not a
form.
> Also, it will only work if filing is in the WORK alias which is not what
you
> want.
I included this to show Jim that he was right - that I had not used aliases
in the path names.
Stephen
Stephen Ford
Jim
> Every form that uses a table has a data model. Don't confuse the separate
> construct that Paradox calls a Data Model with what we're discussing here.
Got to that level of confusion :-}
> My references for detecting if you used an alias were for an older version
> of Pdox - in P9 once you have placed a table into your data model (Format,
> Data Model) you can check if the alias has been assigned by right clicking
> on a table in the data model (the right pane) and selecting Filter. This
> will pop up a dialog box that will show the tables in your model so far
and
> it will show the aliases in front of each table in use if you have used
> aliases.
No aliases shown.
> You click on the dropdown of aliases that is in the left pane right above
> the current folder's contents to select the alias you want. If you don't
> select an alias, then when you look at the Filter conditions, you will
only
> see the table names without alias names in front of them.
I think I'm there ... now to perhaps use Dennis' method to add aliases in
the correct places?
> And to finish - your last example :
>
> >
> > itemTC.open("filing.db")
> >
>
> you should have an alias in front of the "filing.db" name. Always use
an
> alias when you are opening something external to your current file (form,
> script, library) so that the system knows where to look for it.
I suspected so from your previous comments - thanks
Stephen
Stephen Ford
Tony
> If the form opens a table and gets data, then opens other tables and
> adds/inserts/changes data, this could all be done with tcursors - and no
> data model is needed.
>
> So, while I agree with what you mean (I think), I have to disagree with
the
> bare statement.
>
> "Every form on which is placed a table object (MRO/TF) and/or [bare] field
> has a data model" is closer, I think.
This code is attached to a button on the form. Was puzzled by "... this
could all be done with tcursors - and no data model is needed. ..."
method pushButton(var eventInfo Event)
;Description
; Lists the first filing "item" numbers that is missing from the contiguous
sequence. For example
; if there are items 1, 2, 4.. it lists 3. If there are no missing numbers
in the sequence, it
; lists the last plus one.
;Modification History
; Date Details
;20000328 Added ItemFound so that the case where there are no missing
numbers forces the
; last plus one to be listed.
;20020507 Moved ItemFound flag before quitloop
;
var
myCurrentItemNmr SmallInt
myNextItemNmr SmallInt
itemTC TCursor
ItemFound Logical
endVar
; Set found flag (F)
ItemFound = False
; get the first item number
itemTC.open("filing.db")
itemTC.locatePattern("Item", "@..")
myCurrentItemNmr = itemTC.Item
; read all item numbers
while itemTC.locateNextPattern ("Item", "@..")
; * until no more
; read next item number
myNextItemNmr = itemTC.Item
; Compare current and next
if myNextItemNmr > myCurrentItemNmr + 1 then
; o next > current +1
; message
; Quit loop
ItemFound = True
message("The next item is "+ StrVal(myCurrentItemNmr + 1))
quitLoop
endif
; set current item nmr (Next item)
myCurrentItemNmr = myNextItemNmr
endwhile
; Check for item found
if NOT ItemFound then
message("No gaps in the item list. The next item is "+
StrVal(myCurrentItemNmr + 1))
endif
; o no found (no missing item numbers)
; list the last + 1
endmethod
Dennis Santoro
Better to change the alias as described in my Database Basics paper. You can do
it the other way but you won't necessarily get all the references changed if
that is not the only one. Given your description it sounds like you have bare
fields on the form rather than having them contained in an MRO or Tableframe
(which you should have them in!) so you would have to do it field by field.
Better to do it in one shot and then get those shivering bare fields into a
container once you fix the reference.
Stephen Ford
Dennis
>...Given your description it sounds like you have bare
> fields on the form rather than having them contained in an MRO or
Tableframe
> (which you should have them in!) so you would have to do it field by
field.
> Better to do it in one shot and then get those shivering bare fields into
a
> container once you fix the reference.
Seems like this is the case - I'm too much of a novice to have realised the
significance of using as container. To me, that would have been an
unnecessary bit of extra work, but noe I see the benefit. Still, they say
you learn something every day.
Thanks
Stephen
Dennis Santoro
That's only one of the benefits. The big one is you get the default behaviors
of the container and the record object. Check out my paper on Containership on
forms for more on that. Its on our Paradox resources page (link in my
signature).
Denn Santoro
Steve Caple
Stephen Ford wrote:
> I meant there wasn't a "saved" data model. My post above yours still
> applies.
As does mine: a "saved" dm file is rarely of any use, and is of no
importance to your situation.
- create your application database alias if you don't already have one
- create a blank form
- open data model dialog
- select your app alias from the dropdown
- THEN select the table[s]
- right click on each table object and assign a table alias
(I prefer table name in ALLCAPS)
- define table links
- don't bother saving a .DM file, the dm is part of the form
Now you have the basis of a robust and transportable form.
--
Steve
Re-defeat Bush in 2004
Stephen Ford
Steve
> - create your application database alias if you don't already have one
> - create a blank form
> - open data model dialog
> - select your app alias from the dropdown
> - THEN select the table[s]
> - right click on each table object and assign a table alias
> (I prefer table name in ALLCAPS)
> - define table links
> - don't bother saving a .DM file, the dm is part of the form
Great, thanks. Seems obvious now you spell it out - I can even imagine being
able to relocate the database once I've implemented the aliases - Bliss.....
:-)
Thanks
Stephen
Stephen Ford
Dennis
My goodness I'm going to be busy - what am I saying? - I AM busy. Phew!
If only I could be like Maggie Thatcher - survive on 5 hours sleep a night I
mean ...
Already read about normalisation ... the remainder is on the pile of "things
to read".
Many thanks. I will try to make progress and report back. I'm sure it'll all
work.
Regards
Stephen
Dennis Santoro
Sometimes learning the stuff up front saves a ton of time on the back end. ;-)
Steve Caple
Stephen Ford wrote:
> I can even imagine being
> able to relocate the database once I've implemented the aliases - Bliss.....
Dennis mentioned what I left out: always use a table management uiObject
(tableFrame or MRO - a 1x1 record MRO in the following instance) and
don't just put fields on the bare page like the "expert" does when you
choose a form sgowing one record of the "master" table.
Another tip on coding forms: always use quotes around field names, whether
in a uiObject or tCursor. I like to set table aliases in the dm to the
table name in caps so that when I later create an MRO or tableFrame and
define the record the object name property that it defaults to is
self-explanatory: when you look at code that says STUDENT."LastName" or
tcStudent."LastName" you immediately know what you're dealing with.
Stephen Ford
Steve
> .. don't just put fields on the bare page like the "expert" does when you
> choose a form sgowing one record of the "master" table.
....like I've been doing. :-}
> Another tip on coding forms: always use quotes around field names,
whether
> in a uiObject or tCursor. I like to set table aliases in the dm to the
> table name in caps so that when I later create an MRO or tableFrame and
> define the record the object name property that it defaults to is
> self-explanatory: when you look at code that says STUDENT."LastName" or
> tcStudent."LastName" you immediately know what you're dealing with.
Tips noted
Thanks
Stephen
Dennis Santoro
Yup, that is the point. Thanks for getting back to us.