Basic setup of db development into/onto existing accounts in d3Win
78 views
Skip to first unread message
David Knight
Apr 2, 2012, 4:29:05 AM4/2/12
to DesignBais-Forum
Hi,
Have just 'migrated' from db UV [which gave me fits because I am not a
UV person] to d3Win using db v6. After a few hiccoughs, I think we
have got a basic install of v6 along with d3Win to talk to each other.
However, I now have the next issue, for which I cannot find anything
in the documentation.
I assume db has to 'setup' various Q-pointers, catalog programs etc in
a target d3 data account so that it can point to and execute db.
However, I cannot find reference to any setup command.
Typically, I would expect there to be a routine run from TCL in [say]
DBI which would prompt for the account name of the target d3 data
account which would then write into the MD of that target all of the
necessary entries etc.
Anybody know of such a thing?
All I see in the manual & webinars are instructions on how to identify
to db a specific file; but surely one has to at least setup the
account first so it is 'db aware'?
Ideas?
Cheers
David
Have just 'migrated' from db UV [which gave me fits because I am not a
UV person] to d3Win using db v6. After a few hiccoughs, I think we
have got a basic install of v6 along with d3Win to talk to each other.
However, I now have the next issue, for which I cannot find anything
in the documentation.
I assume db has to 'setup' various Q-pointers, catalog programs etc in
a target d3 data account so that it can point to and execute db.
However, I cannot find reference to any setup command.
Typically, I would expect there to be a routine run from TCL in [say]
DBI which would prompt for the account name of the target d3 data
account which would then write into the MD of that target all of the
necessary entries etc.
Anybody know of such a thing?
All I see in the manual & webinars are instructions on how to identify
to db a specific file; but surely one has to at least setup the
account first so it is 'db aware'?
Ideas?
Cheers
David
Rick Weiser
Apr 2, 2012, 7:17:38 AM4/2/12
to designba...@googlegroups.com
David,
The best way to do this is to make a copy of the DBI.DEMO account. For D3, save the account and restore it to a new name. Then in designbais, open the user using the "Users" menu option and add the account to the account list. If you make this account the first account then the next time you log in, this will be the active account. Otherwise, you can use the Change account from the top menu.
Once this is completed, you can open a TCL session in the account and setup q-pointers for the data files.
I hope this helps,
Rick
David Knight
Apr 2, 2012, 11:25:10 PM4/2/12
to DesignBais-Forum
Hi Rick,
Thanks for the info, but in my case I prefer to have the data account
actually be a valid db account. This is for ongoing purposes with
clients who have multiple application data accounts.
So, taking what you said & applying it differently; [I repeat this for
other d3 users], I did the following at TCL in my target data account:
SET-FILE DBI.DEMO MD <enter> [Creates an MD entry called 'QFILE'
which 'points' to the Master Dictionary of DBI.DEMO]
SELECT QFILE = "DBI]" AND WITH *A1 = "Q" <Enter> [Selects all the
MD entries in DBI.DEMO that are q-pointers begiining with 'DBI'. It
selects a goodly number!]
COPY QFILE <Enter> [then at the "TO:" prompt which then appears]
(MD <Enter> [Note the left round bracket. This will copy all the Q-
Pointer entries from DBI.DEMO to the Master Dictionary of the account
you are sitting in, this making the same DBI files available as in
DBI.DEMO]
We then need to catalog all the DBI programs:
SELECT DICT DBI <Enter> [We have to use DICT because there is no
corresponding source code in the Data level of DBI, so we have to
select the dictionary entries which will include anything compiled]
CATALOG DICT DBI
Note, with this last command, anything in the dictionary which is NOT
a compiled object code will not catalog & will generate an error,
which can be safely ignored.
Theoretically, that should now make the data account have the 'same'
setup as DBI.DEMO, thus achieving the same outcome as your suggestion
except without having to make q-pointers to live data files.
Did I miss something?
Cheers
David
Thanks for the info, but in my case I prefer to have the data account
actually be a valid db account. This is for ongoing purposes with
clients who have multiple application data accounts.
So, taking what you said & applying it differently; [I repeat this for
other d3 users], I did the following at TCL in my target data account:
SET-FILE DBI.DEMO MD <enter> [Creates an MD entry called 'QFILE'
which 'points' to the Master Dictionary of DBI.DEMO]
SELECT QFILE = "DBI]" AND WITH *A1 = "Q" <Enter> [Selects all the
MD entries in DBI.DEMO that are q-pointers begiining with 'DBI'. It
selects a goodly number!]
COPY QFILE <Enter> [then at the "TO:" prompt which then appears]
(MD <Enter> [Note the left round bracket. This will copy all the Q-
Pointer entries from DBI.DEMO to the Master Dictionary of the account
you are sitting in, this making the same DBI files available as in
DBI.DEMO]
We then need to catalog all the DBI programs:
SELECT DICT DBI <Enter> [We have to use DICT because there is no
corresponding source code in the Data level of DBI, so we have to
select the dictionary entries which will include anything compiled]
CATALOG DICT DBI
Note, with this last command, anything in the dictionary which is NOT
a compiled object code will not catalog & will generate an error,
which can be safely ignored.
Theoretically, that should now make the data account have the 'same'
setup as DBI.DEMO, thus achieving the same outcome as your suggestion
except without having to make q-pointers to live data files.
Did I miss something?
Cheers
David
Rick Weiser
Apr 5, 2012, 1:58:06 PM4/5/12
to designba...@googlegroups.com
David,
No. There are files that need to be created, fields that need to be copied. After reading this, I still believe that the best way is to separate your application from your data. In your case, you would have 2 D3 accounts for each client; One that holds the data for the account and the other that stores the DB files (copy of DBI.DEMO). This is the safest, easiest and fastest way to duplicate the environment for new clients.
Rick
No. There are files that need to be created, fields that need to be copied. After reading this, I still believe that the best way is to separate your application from your data. In your case, you would have 2 D3 accounts for each client; One that holds the data for the account and the other that stores the DB files (copy of DBI.DEMO). This is the safest, easiest and fastest way to duplicate the environment for new clients.
Rick
Tony Gravagno
Apr 5, 2012, 3:57:09 PM4/5/12
to designba...@googlegroups.com
PMJI…
I know it's possible to dynamically generate the files and props and pointers, and to have data files in different accounts assigned dynamically at run-time … because I did it 5 years ago. In fact I think a couple DB apps still do this. I just looked on my blog and I guess I never published the code, sorry. But it's all possible.
The product is capable of doing more than what DBI likes to support. I'm reminded of a blog I wrote specifically about generating DBIFILES and DBIFORMS and extending DesignBais beyond the vendor constraints (dare I say, hacking DesignBais…):
http://nebula-rnd.com/blog/tech/mv/2007/09/extending-designbais1.html
In the left margin click the DesignBais Category for more fun. (Note that's all pre-v4.3 but I'm sure most of it still applies today.)
The down side of doing all of this account copying comes when it's time to upgrade. Then each DBI.DEMO copy needs to be modified manually to agree with the new release. It would be so much better if there was an installer like David is asking about - the kind most other tools and applications in our industry use. Like I said, I wrote one and it looks like David is on his way there too. Then each app account could be readily upgraded, and without the burden of having two accounts for every data set.
And BTW, here's some alternate syntax (no need for QFile):
SELECT DBI.DEMO,, = DBI] WITH A1 Q
COPY DBI.DEMO,,
to: (MD
SELECT DICT DBI WITH A1 CC
CATALOG DICT DBI
or, to combine….
SELECT DBI.DEMO,, = DBI] WITH A1 Q VR
COPY DBI.DEMO,,
to: (MD
That copies the catalog entries from DBI.DEMO as well as q-pointers, so no need to catalog separately. Some people start their DBI development by calling their files and programs DBI* like the product. That's a very bad idea specifically because of what's being done here.
HTH
T
David Knight
Apr 6, 2012, 6:36:26 AM4/6/12
to DesignBais-Forum
Hi Tony,
Thanks for the input. Yes I think we are the same 'track'; but I have
no learned some more with assistance from the team at DB; and wish to
share this new-found knowledge with others who may hit the same
issues.
FWIW, part of the problems I was having are because I could not get
the correct set of documents. Something weird happening with
attempting to download pdf files. Both IE7 & Chrome would 'bleep' when
clicking on the link. Bearing in mind the link is actually a db form
[probably an onscreen report] which is trying to open a modal form
with the pdf in it. I dummo, but I couldn't get it to "go" no matter
what I disabled on my system. Anyway, no matter Rick emailed me the
pdfs, which ceratinly helps. So my first tip to others: don't assume
you have all the documents; they are NOT all in the install set; you
need 'flavour' specific instructions and d3 is no different!
Moving on...
My next 'Thank you' is to you Tony for giving me syntax to copy files
from on d3 account to another without the use of Q-Pointers. I knew
that can be done, but have found this type of fully-resolvable
pathname type naming syntactically confusing and hard to remember; so
for an old goat like me, Q-Pointers do the trick!!
Now, this is what I learned today [I may have some minor detail wrong,
but I think this may help most get their head around things].
Firstly db by default is designed to sit inside the one account, for
example DBI.DEMO contains all the definitions AND all the data files
for that 'development'. Some may find that a bit weird, but there you
go. I guess DB still separates 'application' from 'data' while in this
form from the perspective of designbais ITSELF; but that does not
[IMHO] create separation for developed apps. Anyway, the point is:
there is a way to do so & I shall outline the steps here. It is a
combination of what I think everyone has been trying to do, but is
'officially' part of DB:
1. As suggested by Rick, replicate the DBI.DEMO account via some
means. Account-save & account-restore spring to mind as the easiest
method. Give this account a suitable name that makes sens to your app.
This is what I would call a 'program account' but is what DB calls a
'shared' definition account; lets all think of it as the
'application'.
2. In your application DATA account [assuming you already have one, if
not create one] create a pointer to your 'application' account called
DBI which points to the file 'DBI'. Many ways to do that but for me
the easiest is to use SET-FILE {accountname} DBI <Enter> then COPY MD
QFILE (D <Enter> DBI <Enter>.
3. If done correctly you will be able to LIST, SORT or whatever 'DBI'.
Check that.
4. Run a program in DBI called DBI.P.ACCOUNT.SETUP [for which source
is available, so you can read it, too]. If it doesn't run, compile it.
You could catalog it, or simply enter the command RUN DBI
DBI.P.ACCOUNT.SETUP. Now this thing will prompt for a few things, so
be careful. You have to state what environment you are on [Windows/
Unix etc]. You have to state what mv platform you are on [In this case
D3], {here's the important bit} IF YOU WANT TO SPLIT APPLICATION &
DATA you have to respond to the prompt about a Shared definition
account with the name of the account your created in step 1! Really,
really important!! You also have to tell the routine where your
designbais install files are. Note this defaulted to the default
install directory on C:. If you are difficult [like me] and put apps
onto a separate drive; you must mention the correct directory. Mine
was s:\designbais. I think that was it, & off it went copying a bunch
of stuff and setting up other bits too. I recommend reading the source
before you try; just to get your head around what it is doing and
going to ask.
5. Then, I had to simply setup MVSP so that it can 'talk' to my data
account.
6. Finally, back in designbais, in User maintenance for my development
user; I added in the account name for my data account & told it the
default form to use as being the same as DBI.DEMO; & I could then
'Change accounts' to this new account & off we went! Voila!
Ok, that's my news for now. I hope that helps others in case they come
across the same issue.
Happy holidays!
Cheers,
David
On Apr 6, 5:57 am, "Tony Gravagno" <ex2vgh...@sneakemail.com> wrote:
> PMJI.
> > Rick- Hide quoted text -
>
> - Show quoted text -
Thanks for the input. Yes I think we are the same 'track'; but I have
no learned some more with assistance from the team at DB; and wish to
share this new-found knowledge with others who may hit the same
issues.
FWIW, part of the problems I was having are because I could not get
the correct set of documents. Something weird happening with
attempting to download pdf files. Both IE7 & Chrome would 'bleep' when
clicking on the link. Bearing in mind the link is actually a db form
[probably an onscreen report] which is trying to open a modal form
with the pdf in it. I dummo, but I couldn't get it to "go" no matter
what I disabled on my system. Anyway, no matter Rick emailed me the
pdfs, which ceratinly helps. So my first tip to others: don't assume
you have all the documents; they are NOT all in the install set; you
need 'flavour' specific instructions and d3 is no different!
Moving on...
My next 'Thank you' is to you Tony for giving me syntax to copy files
from on d3 account to another without the use of Q-Pointers. I knew
that can be done, but have found this type of fully-resolvable
pathname type naming syntactically confusing and hard to remember; so
for an old goat like me, Q-Pointers do the trick!!
Now, this is what I learned today [I may have some minor detail wrong,
but I think this may help most get their head around things].
Firstly db by default is designed to sit inside the one account, for
example DBI.DEMO contains all the definitions AND all the data files
for that 'development'. Some may find that a bit weird, but there you
go. I guess DB still separates 'application' from 'data' while in this
form from the perspective of designbais ITSELF; but that does not
[IMHO] create separation for developed apps. Anyway, the point is:
there is a way to do so & I shall outline the steps here. It is a
combination of what I think everyone has been trying to do, but is
'officially' part of DB:
1. As suggested by Rick, replicate the DBI.DEMO account via some
means. Account-save & account-restore spring to mind as the easiest
method. Give this account a suitable name that makes sens to your app.
This is what I would call a 'program account' but is what DB calls a
'shared' definition account; lets all think of it as the
'application'.
2. In your application DATA account [assuming you already have one, if
not create one] create a pointer to your 'application' account called
DBI which points to the file 'DBI'. Many ways to do that but for me
the easiest is to use SET-FILE {accountname} DBI <Enter> then COPY MD
QFILE (D <Enter> DBI <Enter>.
3. If done correctly you will be able to LIST, SORT or whatever 'DBI'.
Check that.
4. Run a program in DBI called DBI.P.ACCOUNT.SETUP [for which source
is available, so you can read it, too]. If it doesn't run, compile it.
You could catalog it, or simply enter the command RUN DBI
DBI.P.ACCOUNT.SETUP. Now this thing will prompt for a few things, so
be careful. You have to state what environment you are on [Windows/
Unix etc]. You have to state what mv platform you are on [In this case
D3], {here's the important bit} IF YOU WANT TO SPLIT APPLICATION &
DATA you have to respond to the prompt about a Shared definition
account with the name of the account your created in step 1! Really,
really important!! You also have to tell the routine where your
designbais install files are. Note this defaulted to the default
install directory on C:. If you are difficult [like me] and put apps
onto a separate drive; you must mention the correct directory. Mine
was s:\designbais. I think that was it, & off it went copying a bunch
of stuff and setting up other bits too. I recommend reading the source
before you try; just to get your head around what it is doing and
going to ask.
5. Then, I had to simply setup MVSP so that it can 'talk' to my data
account.
6. Finally, back in designbais, in User maintenance for my development
user; I added in the account name for my data account & told it the
default form to use as being the same as DBI.DEMO; & I could then
'Change accounts' to this new account & off we went! Voila!
Ok, that's my news for now. I hope that helps others in case they come
across the same issue.
Happy holidays!
Cheers,
David
On Apr 6, 5:57 am, "Tony Gravagno" <ex2vgh...@sneakemail.com> wrote:
> PMJI.
>
> I know it's possible to dynamically generate the files and props and
> pointers, and to have data files in different accounts assigned
> dynamically at run-time . because I did it 5 years ago. In fact I
> I know it's possible to dynamically generate the files and props and
> pointers, and to have data files in different accounts assigned
> think a couple DB apps still do this. I just looked on my blog and I
> guess I never published the code, sorry. But it's all possible.
>
> The product is capable of doing more than what DBI likes to support.
> I'm reminded of a blog I wrote specifically about generating DBIFILES
> and DBIFORMS and extending DesignBais beyond the vendor constraints
> (dare I say, hacking DesignBais.):
> guess I never published the code, sorry. But it's all possible.
>
> The product is capable of doing more than what DBI likes to support.
> I'm reminded of a blog I wrote specifically about generating DBIFILES
> and DBIFORMS and extending DesignBais beyond the vendor constraints
>
> http://nebula-rnd.com/blog/tech/mv/2007/09/extending-designbais1.html
>
> In the left margin click the DesignBais Category for more fun. (Note
> that's all pre-v4.3 but I'm sure most of it still applies today.)
>
> The down side of doing all of this account copying comes when it's
> time to upgrade. Then each DBI.DEMO copy needs to be modified manually
> to agree with the new release. It would be so much better if there was
> an installer like David is asking about - the kind most other tools
> and applications in our industry use. Like I said, I wrote one and it
> looks like David is on his way there too. Then each app account could
> be readily upgraded, and without the burden of having two accounts for
> every data set.
>
> And BTW, here's some alternate syntax (no need for QFile):
>
> SELECT DBI.DEMO,, = DBI] WITH A1 Q
>
> COPY DBI.DEMO,,
>
> to: (MD
>
> SELECT DICT DBI WITH A1 CC
>
> CATALOG DICT DBI
>
> or, to combine..
> http://nebula-rnd.com/blog/tech/mv/2007/09/extending-designbais1.html
>
> In the left margin click the DesignBais Category for more fun. (Note
> that's all pre-v4.3 but I'm sure most of it still applies today.)
>
> The down side of doing all of this account copying comes when it's
> time to upgrade. Then each DBI.DEMO copy needs to be modified manually
> to agree with the new release. It would be so much better if there was
> an installer like David is asking about - the kind most other tools
> and applications in our industry use. Like I said, I wrote one and it
> looks like David is on his way there too. Then each app account could
> be readily upgraded, and without the burden of having two accounts for
> every data set.
>
> And BTW, here's some alternate syntax (no need for QFile):
>
> SELECT DBI.DEMO,, = DBI] WITH A1 Q
>
> COPY DBI.DEMO,,
>
> to: (MD
>
> SELECT DICT DBI WITH A1 CC
>
> CATALOG DICT DBI
>
>
> - Show quoted text -
David Knight
Jul 2, 2012, 5:17:05 AM7/2/12
to designba...@googlegroups.com
Here's another little glitch, although not ENTIRELY related to migration:
dbv6 has a Word Index feature. That feature requires a file DBFINDEXDEFN which is NOT created by upgrade/installs or the utility to add db to an existing account. Once has to create it oneself, and copy the dictionary portion from the version found in DBI. This snippet of detail is also NOT documented in the install/release/update or reference manual documentation.
On Monday, April 2, 2012 6:29:05 PM UTC+10, David Knight wrote:
Hi,
Have just 'migrated' from db UV [which gave me fits because I am not a
UV person] to d3Win using db v6. After a few hiccoughs, I think we
have got a basic install of v6 along with d3Win to talk to each other.
<snip>
David Knight
Jul 2, 2012, 8:03:13 AM7/2/12
to designba...@googlegroups.com
Apology: I was wrong. This is documented, on p3 of the v6.13 upgrade notes. The file does need to be manually created if you are upgrading an existing installation. I guess technically I was, although I started with a new install set of db for d3; so missed this item.
I apologise to designBais' staff if I caused any embarrasment via this forum post.
David
David Knight
Jun 30, 2013, 5:02:47 AM6/30/13
to designba...@googlegroups.com, dav...@matash.com.au
This post is more for Rick Weiser, but if anyone else knows; please chime in!
If you read through to the end of this original issue; you will find that to perform an original install onto a d3 system where the data & program 'accounts' are to be different, required the use of a routine called DBI.P.ACCOUNT.SETUP amongst some other 'fiddlies'.
Time has passed, and I am now 'upgrading' our working development installation to v6.4.9; which arrives as a new set of Webserver executables, and a d3 pseudo-tape account save of DBI. Apart from all the web stuff, one has to delete and restore the account DBI in d3.
In my case, this creates an issue since DBI for my 'app' was split and re-written via DBI.P.ACCOUNT.SETUP.
So the question now is; what to do to UPGRADE, in-situ an existing system? Hoping Rick had already written a routine to do just that, I noticed in the 'new' DBI a program called DBI.P.UPDATE.ACCOUNT; the source of which LOOKS like it will do what I want if I run it from TCL in the new program account.
Rick, is that correct? Is there anything else I need do, for example there is also DBI.P.UPDATE.STYLES
Can you please advise?
Thank you
David
Rick Weiser
Jul 1, 2013, 3:23:31 PM7/1/13
to designba...@googlegroups.com, dav...@matash.com.au
David,
What do you mean the DBI account was " split and re-written"? The DBI.P.ACCOUNT.SETUP doesn't do this, it only copies the DBI qpointers into the account. The upgrade process should work exactly as instructed.
If you would like to discuss this then call me.
Rick
David Knight
Jul 2, 2013, 8:53:25 AM7/2/13
to designba...@googlegroups.com, dav...@matash.com.au
Hi Rick,
Hmmm... seems like I may have got meself entirely confused...
Basically my development version is working but I think that may have been a fluke; as I now see what you are getting at. If I may, will you allow me to contrast the SB+ environment as it maybe illuminating.
For my Hoscare system, there are 4 d3 accounts. Two are SB+ related stuff, and two are my Hoscare application stuff. They are SB+ & SB+.DEFN; and <dataaccountname> and MATASHBP. The latter two contain the Hoscare application itself split into a data acount and a 'program' account. It is the latter two accounts which I believe, by default; db prefers to have in the one account. That is, the data for a db app, and the application definitions are in the one account. Not good.
So when it came time to migrate Hoscare into db for development purposes I wanted to retain this basic concept, as for the moment I still need to keep the SB+ version going. That is, as far as Hoscare itself is concerned a given system will have one program account, at least one <dataaccountname> and db itself; which I now assume is simply the account DBI. Because there are no filename clashes, I chose to keep the db Hoscare programs [ie: the db 'version' of my app] in the same account as my SB+ version, namely MATASHBP. So files like DBIFORMS and other 'app' files should be in MATASHBP. Also codeblocks, any source I write for subroutines and so forth.
Somewhere, I think; the wheels fell off and instead of keeping the db version-specific-common stuff seperate in the account DBI; it ended up in MATASHBP too; hence my confusion since simply replacing the DBI account will do nothing.
Therefore, if I am correct, I need to make sure that files/routines specific to a db version which are housed in DBI stay there, and Q-Pointers from my <dataaccount> point there; and files/routines specific to the application generated by db are held in MATASHBP with appropriate q-pointers.
So, now my question is: what are the files which should be in each area?
One way I just thought of is to look in the MD of DBI.DEMO and see what Q-pointer entries there are which point to DBI; and copy those into my data account's MD. This I did, and [surprise] it did not seem to break db when I ran my app. Secondly, I need to know the db files within a db-built app, which are specific to the app, but are not 'data' itself. such as DBFORMS, DBMENUS, and which ones should remain in the data account as Word index files. Do you have any suggestions?
I hope this makes a little more sense now.
Once sorted correctly, updates that replace the DBI account should work just fine!
PS: I'd be happy to call you Rick, but timezone differences are a bitch!
Cheers,
David
Rick Weiser
Jul 2, 2013, 2:14:11 PM7/2/13
to designba...@googlegroups.com, dav...@matash.com.au
Yes, David, please call me. I think that we can work this out very quickly over the phone. I have no problem staying late to talk to about this if you can't meet in the morning.
Let me know when you are available and I will make sure that I am also.
Rick
Reply all
Reply to author
Forward
0 new messages