Re: USE DATABASE from a component. ?

[Keisuke Miyako via 4D_Tech]

that you can avoid by passing AUTO_CLOSE.

the advantage of not using AUTO_CLOSE is that the structure definition of the 
external database is cached,
so subsequent access becomes faster.
it's useful, for example, if you want to switch contexts several times.

2017/05/30 9:12、David Adams via 4D_Tech 
<4d_tech@lists.4d.com> のメール：

* There are some options on how to do the path. I found converting to Posix
on macOS let me use the file once but afterwards it remained open and
locked. (And only unlockable by quitting 4D.)



**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: USE DATABASE from a component. ?

[Keisuke Miyako via 4D_Tech]

that's the idea.
Component.4DC would have an empty placeholder
Component.4DD,
even if Component and Product were in fact identical.

whether to put the data inside Resources
is a decision based on whether you want the data to be sent to the client.

although you can place multiple 4DB/4DC/4DD inside a 4dbase,
there is a warning displayed once
if you open a structure whose name doesn't match that of the package.

2017/05/30 8:32、David Adams via 4D_Tech 
<4d_tech@lists.4d.com> のメール：

Component.4dbase
  Component.4DC
  Products.4DB
  Products.4DD

Or

  Component.4DC
  Resources
   Products.4DB
   Products.4DD

Something like that. The code is in Component.4DC, the structure definition
is in Products.4DB and the data is in Products.4DD.

Is that the idea? If so, I can make that work.



**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: USE DATABASE from a component. ?

[David Adams via 4D_Tech]

Keisuke,

I'm not worthy! Once again, you got to the heart of the problem with a
solid technical answer. Better than that you've corrected my mental map of
the underlying feature. That's even more helpful.

Since I didn't stumble across this stated succinctly in the docs, here's a
summary of my understanding. If this is right, it would be great to see
something comparable in the docs. If it's wrong, corrections will be
appreciated.

* A component (compiled or not) can switch to another data file temporarily
using code like this in a SQL block:

   USE DATABASE DATAFILE :$application_data_path;

* There are some options on how to do the path. I found converting to Posix
on macOS let me use the file once but afterwards it remained open and
locked. (And only unlockable by quitting 4D.) So I'm using a full path
based on OS syntax.

* At the base, there are three files involved in the process within a
component. I'm putting the data-related files into the /Resources folder of
the component. This makes it easy to find, easy to manage, allows 4D to
automatically copy the files for me when building the component, and seems
(?) to avoid permissions errors.

* Here are the three files:

Component.4DC This is where all of your code lives.
External.4DB  This is the structure for the external data. *No code in
this structure is accessible.*
External.4DD  This is the data mapped by External.4DB

* Oh, don't forget to close the external file when you're done:

USE DATABASE SQL_INTERNAL;

I think that's it. It seems to work smoothly now. Any corrections or
amendments?
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: USE DATABASE from a component. ?

[David Adams via 4D_Tech]

On Tue, May 30, 2017 at 8:57 AM, Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> opening a 4DC/4DD pair as an external database does not make sense.
>

I think you mave have pushed me over the line towards understand here. I
was using a 4DD associated with the source of the component itself. Because
it was there. In fact, I can compile the component and include a .4DD from
anywhere, is that right? What's confusing is that you don't specify a data
file, you seem to specify a *structure* file. If I'm understanding
correctly, I'd have something like this:

Component.4dbase
   Component.4DC
   Products.4DB
   Products.4DD

Or

   Component.4DC
   Resources
Products.4DB
Products.4DD

Something like that. The code is in Component.4DC, the structure definition
is in Products.4DB and the data is in Products.4DD.

Is that the idea? If so, I can make that work.
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: USE DATABASE from a component. ?

[Keisuke Miyako via 4D_Tech]

opening a 4DC/4DD pair as an external database does not make sense.
I mean, it kind of makes sense,
but I can't see why it has to be done using a 4DC.

there are not methods, including triggers, to call in that context,
so what is the virtue of the structure file being compiled?

you can create a 4DB with no form, menus or users using SQL,
you can create a 4DB with no code from an XML definition.

in any case, the 4DD is what you really want to open;
just go ahead with 4DB, the result is exactly the same.

2017/05/29 15:09、David Adams via 4D_Tech 
<4d_tech@lists.4d.com> のメール：

I've manually changed permissions on all of the files to be...generous.
(What's up with that? Is this normally required? It seems so in my case on
OS X.)

I've tried opening up the .4DC from inside of the component and selecting
the .4DD right next to it before moving the component over to the host. No
help.

I've tried specifying .4DC in the USE DATABASE path, but that doesn't work
at all.

Suggestions appreciated.



**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: USE DATABASE from a component. ?

[David Adams via 4D_Tech]

Hey, thanks for the answers and background! I'd never heard that thing
about having to create the data file with SQL in order to use it as an
external data file. I guess that's not true now...I guess?

In it's simplest form, my question is: How do I open an external file from
a compiled component?

Is anyone doing this? How did you make it work?
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: USE DATABASE from a component. ?

[Keisuke Miyako via 4D_Tech]

are you sure that the index is "embedded"?

it's true that an external database created using SQL does not have an 
accompanying 4DIndx,
but an MSC repair would add one.

and if you open that database with USE DATABASE,
the 4DIndx is opened too,
so I would assume that the index is external to the 4DD.

2017/05/29 22:20、Tim Nevels via 4D_Tech 
<4d_tech@lists.4d.com> のメール：

I think you do have to create the external data file with SQL. It has a special 
format. Notice that if you index fields in the external data file it does not 
create a .4dindx file. The index is embedded inside the data file.

"Normal" 4D data files have the indexes stored in "segment 64" which is the 
.4dindx file. Segments didn't die, they are just hidden from us.



**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: USE DATABASE from a component. ?

[Keisuke Miyako via 4D_Tech]

yes, the original (during beta) specification was that an external database 
must be created using SQL,
but that changed in the release of v12, as explained in the documentation:

An external database is a standard 4D database. It can be opened and worked 
with as the main database by a 4D or 4D Server application. Conversely, any 
standard 4D database can be used as an external database.

http://doc.4d.com/4Dv15/4D/15/CREATE-DATABASE.300-2288130.en.html

incidentally, I wrote a tool that generates SQL to replicate a 4DB
https://github.com/miyako/4d-utility-structure-to-sql-converter
but that is pretty much useless now...

2017/05/29 20:54、Wayne Stewart via 4D_Tech 
<4d_tech@lists.4d.com> のメール：
The other possibility is I may be recalling a restriction from a previous
version or beta of course.



**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: USE DATABASE from a component. ?

[Tim Nevels via 4D_Tech]

On May 29, 2017, at 10:56 AM, David Adams wrote:

> Hey Wayne, thanks for answering. I think that external .4DD files were
> created for use from components in the first place and I've made it work
> before...but it's been years. I don't remember hearing that you had to
> create the data file from SQL, I thought that you could use any data file
> that you like. It's all working with an interpreted component, so I don't
> know what to make of it.

I think you do have to create the external data file with SQL. It has a special 
format. Notice that if you index fields in the external data file it does not 
create a .4dindx file. The index is embedded inside the data file. 

"Normal" 4D data files have the indexes stored in "segment 64" which is the 
.4dindx file. Segments didn't die, they are just hidden from us. 

Tim

Sent from my iPhone!
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: USE DATABASE from a component. ?

[Wayne Stewart via 4D_Tech]

I just looked at the docs again. The problem is (from the create database
page):

However, it is imperative that you do not activate the access management
system (by assigning a password to the Designer) in an external database,
otherwise you will no longer be able to have access to it via the USE
DATABASEcommand.

The other possibility is I may be recalling a restriction from a previous
version or beta of course.

On Mon, 29 May 2017 at 21:50, Wayne Stewart 
wrote:

> David,
>
> A lot of my comments were tongue in cheek but I'm sure I heard that once
> an external data file is opened in real 4D it buggers it up from then on as
> an external database
>
> Wayne
>
> On Mon, 29 May 2017 at 18:56, David Adams via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
>
>> Hey Wayne, thanks for answering. I think that external .4DD files were
>> created for use from components in the first place and I've made it work
>> before...but it's been years. I don't remember hearing that you had to
>> create the data file from SQL, I thought that you could use any data file
>> that you like. It's all working with an interpreted component, so I don't
>> know what to make of it.
>>
>> It looks like you're a tiny bit suspicious of SQL. Don't be! And
>> definitely
>> don't confuse 4D's SQL with SQL per se. 4D's implementation is and has
>> always been a big disappointment, and there doesn't seem to be much (any?)
>> activity towards improving it. In normal SQL environments, there are a few
>> really nice features:
>>
>> * Basic SQL commands are fun and easy.
>>
>> * It's great for just poking around and exploring new data. Very nice.
>>
>> * Aggregate functions in SQL are _great_. Just awesome.
>>
>> * Views (depending on implementation) are super nice. You can create a
>> virtual table that is itself the product of a search and then search
>> against that, it's really nice.
>>
>> * In the SQL world, people tend to do decent database designs. That's a
>> Very Good Thing. > databases.
>> They have their uses. Standard business apps? Not so much.>
>>
>> Now, when it comes to complex multi-table joins? Well, that's harder. But
>> for the easy stuff, SQL is just great.
>>
>> I've always loved the idea of external data files - there are so many good
>> ways they _could_ be used. Imagine you've got a part catalog that gets
>> updated once a quarter. Let's say it has 200,000 items. Well, if it's in
>> an
>> external file, you can cache it locally on the client. Download it once
>> and
>> access it locally - no network traffic for lookups! Local caches are a
>> super useful tool in some settings. I never did understand why 4D promoted
>> the REMOTE option under 4D Server. The idea there is that there's an
>> external 4DD on the server side that one client at a time could use. Sort
>> of a file sharing database server. Struck me as a giant exercise in
>> missing
>> the point entirely.
>>
>> But back to local caches. Apart from static lookups, you could also use
>> them for logging data that you later collect/summarize and send somewhere.
>> Or perhaps you have a stand-alone app that needs to queue up changes for
>> processing when connected to a network, etc., etc. You can implement local
>> caches using custom disk files or a command-line interface onto a headless
>> database...but that's kind of a lot of work. With a local data file
>> accessed via 4D, you're getting a full database with indexes and the whole
>> nine yards. Seems like a great idea. Somehow it never caught on, the SQL
>> is
>> hard to work with, and the docs are inadequate :( Better docs might make a
>> big difference all by themselves, in this case. (I may be missing
>> something, pointers welcome.)
>>
>> Anyway, the point of this external file is to hoist data from the
>> component
>> into the host database. That's 100% the reason to have the data file in
>> the
>> component, so I'm just trying to figure out how to make that work
>> compiled.
>>
>> Thanks for any suggestions - I think others have worked through this.
>>
>> Here's a fragment of my code including the bit that sets the path:
>>
>>
>>
>> //-
>>   // Copy data from external .4DD using SQL commands
>>
>>
>> //-
>> ARRAY TEXT($names_at;0)
>> ARRAY TEXT($hosts_at;0)
>> ARRAY TEXT($advantages_at;0)
>> ARRAY TEXT($companies_at;0)
>> ARRAY TEXT($slogans_at;0)
>>
>>   // Place the .4DD you want to use in the component.
>>   // This is a manual step, but you can write code to take care of it for
>> you.
>>   // (The 4D Component Build screen does not offer this as an automatic
>> action.)
>>
>>   // Note: You may need to adjust file permissions to allow it to run
>> correctly.
>>
>>   // Note: Notice that we don't specify a file extension.
>> C_TEXT(Apps_File_Path)
>> Apps_File_Path:=Get 4D folder(Database 

Re: USE DATABASE from a component. ?

[Wayne Stewart via 4D_Tech]

David,

A lot of my comments were tongue in cheek but I'm sure I heard that once an
external data file is opened in real 4D it buggers it up from then on as an
external database

Wayne

On Mon, 29 May 2017 at 18:56, David Adams via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> Hey Wayne, thanks for answering. I think that external .4DD files were
> created for use from components in the first place and I've made it work
> before...but it's been years. I don't remember hearing that you had to
> create the data file from SQL, I thought that you could use any data file
> that you like. It's all working with an interpreted component, so I don't
> know what to make of it.
>
> It looks like you're a tiny bit suspicious of SQL. Don't be! And definitely
> don't confuse 4D's SQL with SQL per se. 4D's implementation is and has
> always been a big disappointment, and there doesn't seem to be much (any?)
> activity towards improving it. In normal SQL environments, there are a few
> really nice features:
>
> * Basic SQL commands are fun and easy.
>
> * It's great for just poking around and exploring new data. Very nice.
>
> * Aggregate functions in SQL are _great_. Just awesome.
>
> * Views (depending on implementation) are super nice. You can create a
> virtual table that is itself the product of a search and then search
> against that, it's really nice.
>
> * In the SQL world, people tend to do decent database designs. That's a
> Very Good Thing.  They have their uses. Standard business apps? Not so much.>
>
> Now, when it comes to complex multi-table joins? Well, that's harder. But
> for the easy stuff, SQL is just great.
>
> I've always loved the idea of external data files - there are so many good
> ways they _could_ be used. Imagine you've got a part catalog that gets
> updated once a quarter. Let's say it has 200,000 items. Well, if it's in an
> external file, you can cache it locally on the client. Download it once and
> access it locally - no network traffic for lookups! Local caches are a
> super useful tool in some settings. I never did understand why 4D promoted
> the REMOTE option under 4D Server. The idea there is that there's an
> external 4DD on the server side that one client at a time could use. Sort
> of a file sharing database server. Struck me as a giant exercise in missing
> the point entirely.
>
> But back to local caches. Apart from static lookups, you could also use
> them for logging data that you later collect/summarize and send somewhere.
> Or perhaps you have a stand-alone app that needs to queue up changes for
> processing when connected to a network, etc., etc. You can implement local
> caches using custom disk files or a command-line interface onto a headless
> database...but that's kind of a lot of work. With a local data file
> accessed via 4D, you're getting a full database with indexes and the whole
> nine yards. Seems like a great idea. Somehow it never caught on, the SQL is
> hard to work with, and the docs are inadequate :( Better docs might make a
> big difference all by themselves, in this case. (I may be missing
> something, pointers welcome.)
>
> Anyway, the point of this external file is to hoist data from the component
> into the host database. That's 100% the reason to have the data file in the
> component, so I'm just trying to figure out how to make that work compiled.
>
> Thanks for any suggestions - I think others have worked through this.
>
> Here's a fragment of my code including the bit that sets the path:
>
>
>
> //-
>   // Copy data from external .4DD using SQL commands
>
>
> //-
> ARRAY TEXT($names_at;0)
> ARRAY TEXT($hosts_at;0)
> ARRAY TEXT($advantages_at;0)
> ARRAY TEXT($companies_at;0)
> ARRAY TEXT($slogans_at;0)
>
>   // Place the .4DD you want to use in the component.
>   // This is a manual step, but you can write code to take care of it for
> you.
>   // (The 4D Component Build screen does not offer this as an automatic
> action.)
>
>   // Note: You may need to adjust file permissions to allow it to run
> correctly.
>
>   // Note: Notice that we don't specify a file extension.
> C_TEXT(Apps_File_Path)
> Apps_File_Path:=Get 4D folder(Database folder)+"DataPatch"
> Apps_File_Path:=Convert path system to POSIX(Apps_File_Path)
>
> C_TEXT($check_path)  // We don't use this variable. It's here to show you
> how to check the name of the data file when you change it with USE DATABASE
> DATAFILE.
> $check_path:=""
>
> Begin SQL
> USE DATABASE DATAFILE :Apps_File_Path;
> SELECT DATABASE_PATH()
> FROM _USER_SCHEMAS
> LIMIT 1
> INTO :$check_path;
> SELECT  App_Name,
> App_Host,
> Advantage,
> Company,
> Slogan
> FROM   App_Definitions_to_Move
> INTO   :$names_at,
> :$hosts_at,
> :$advantages_at,
> :$companies_at,
> :$slogans_at;
> USE DATABASE SQL_INTERNAL;
> End SQL
> 

Re: USE DATABASE from a component. ?

[David Adams via 4D_Tech]

Hey Wayne, thanks for answering. I think that external .4DD files were
created for use from components in the first place and I've made it work
before...but it's been years. I don't remember hearing that you had to
create the data file from SQL, I thought that you could use any data file
that you like. It's all working with an interpreted component, so I don't
know what to make of it.

It looks like you're a tiny bit suspicious of SQL. Don't be! And definitely
don't confuse 4D's SQL with SQL per se. 4D's implementation is and has
always been a big disappointment, and there doesn't seem to be much (any?)
activity towards improving it. In normal SQL environments, there are a few
really nice features:

* Basic SQL commands are fun and easy.

* It's great for just poking around and exploring new data. Very nice.

* Aggregate functions in SQL are _great_. Just awesome.

* Views (depending on implementation) are super nice. You can create a
virtual table that is itself the product of a search and then search
against that, it's really nice.

* In the SQL world, people tend to do decent database designs. That's a
Very Good Thing. 

Now, when it comes to complex multi-table joins? Well, that's harder. But
for the easy stuff, SQL is just great.

I've always loved the idea of external data files - there are so many good
ways they _could_ be used. Imagine you've got a part catalog that gets
updated once a quarter. Let's say it has 200,000 items. Well, if it's in an
external file, you can cache it locally on the client. Download it once and
access it locally - no network traffic for lookups! Local caches are a
super useful tool in some settings. I never did understand why 4D promoted
the REMOTE option under 4D Server. The idea there is that there's an
external 4DD on the server side that one client at a time could use. Sort
of a file sharing database server. Struck me as a giant exercise in missing
the point entirely.

But back to local caches. Apart from static lookups, you could also use
them for logging data that you later collect/summarize and send somewhere.
Or perhaps you have a stand-alone app that needs to queue up changes for
processing when connected to a network, etc., etc. You can implement local
caches using custom disk files or a command-line interface onto a headless
database...but that's kind of a lot of work. With a local data file
accessed via 4D, you're getting a full database with indexes and the whole
nine yards. Seems like a great idea. Somehow it never caught on, the SQL is
hard to work with, and the docs are inadequate :( Better docs might make a
big difference all by themselves, in this case. (I may be missing
something, pointers welcome.)

Anyway, the point of this external file is to hoist data from the component
into the host database. That's 100% the reason to have the data file in the
component, so I'm just trying to figure out how to make that work compiled.

Thanks for any suggestions - I think others have worked through this.

Here's a fragment of my code including the bit that sets the path:


//-
  // Copy data from external .4DD using SQL commands

//-
ARRAY TEXT($names_at;0)
ARRAY TEXT($hosts_at;0)
ARRAY TEXT($advantages_at;0)
ARRAY TEXT($companies_at;0)
ARRAY TEXT($slogans_at;0)

  // Place the .4DD you want to use in the component.
  // This is a manual step, but you can write code to take care of it for
you.
  // (The 4D Component Build screen does not offer this as an automatic
action.)

  // Note: You may need to adjust file permissions to allow it to run
correctly.

  // Note: Notice that we don't specify a file extension.
C_TEXT(Apps_File_Path)
Apps_File_Path:=Get 4D folder(Database folder)+"DataPatch"
Apps_File_Path:=Convert path system to POSIX(Apps_File_Path)

C_TEXT($check_path)  // We don't use this variable. It's here to show you
how to check the name of the data file when you change it with USE DATABASE
DATAFILE.
$check_path:=""

Begin SQL
USE DATABASE DATAFILE :Apps_File_Path;
SELECT DATABASE_PATH()
FROM _USER_SCHEMAS
LIMIT 1
INTO :$check_path;
SELECT  App_Name,
App_Host,
Advantage,
Company,
Slogan
FROM   App_Definitions_to_Move
INTO   :$names_at,
:$hosts_at,
:$advantages_at,
:$companies_at,
:$slogans_at;
USE DATABASE SQL_INTERNAL;
End SQL
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: USE DATABASE from a component. ?

[Wayne Stewart via 4D_Tech]

David,

The only database available from a component is the host database.

You can access it via pointers, (works for me).

Or you can create a table in the host via SQL (although I prefer to avoid
Satan's QL):

http://doc.4d.com/4Dv16/4D/16/CREATE-TABLE.300-3201315.en.html

But if you are heading off into those demonic regions…

You can also create and access an external datafile (via SQL) again:

http://doc.4d.com/4Dv16/4D/16/CREATE-DATABASE.300-3201304.en.html

May God have mercy upon your soul…

So, I'm guessing what you need to do is:
1. create the datafile via SQL (you can't use a normal .4DD) in your matrix
database with an "identical structure" to the one you wish to use
2. transfer the data into it from the matrix database into it
3. include that external .4DD in the component for access at runtime.

NB.  Once a file created that way is opened by a real 4D, then all demonic
influences are exorcised from it and it can no longer be used as an
external data file (which I think is the problem you are having).




Regards,

Wayne


[image: --]
Wayne Stewart
[image: http://]about.me/waynestewart



On 29 May 2017 at 16:09, David Adams via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> I've done this before but years ago - more than five. I really like the
> idea of external .4DD files, but have not mastered the niceties of the
> paths and such.
>
> I've got a simple setup with a component that includes a .4DD file. I want
> the component to open up and use the data file. I've gotten this working
> when everything is interpreted. With a compiled component, I get a stack of
> errors, starting with error -43, file not found. The error stack that it's
> looking for a .4DB file, not a .4DC file.
>
> I've manually changed permissions on all of the files to be...generous.
> (What's up with that? Is this normally required? It seems so in my case on
> OS X.)
>
> I've tried opening up the .4DC from inside of the component and selecting
> the .4DD right next to it before moving the component over to the host. No
> help.
>
> I've tried specifying .4DC in the USE DATABASE path, but that doesn't work
> at all.
>
> Suggestions appreciated.
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

USE DATABASE from a component. ?

[David Adams via 4D_Tech]

I've done this before but years ago - more than five. I really like the
idea of external .4DD files, but have not mastered the niceties of the
paths and such.

I've got a simple setup with a component that includes a .4DD file. I want
the component to open up and use the data file. I've gotten this working
when everything is interpreted. With a compiled component, I get a stack of
errors, starting with error -43, file not found. The error stack that it's
looking for a .4DB file, not a .4DC file.

I've manually changed permissions on all of the files to be...generous.
(What's up with that? Is this normally required? It seems so in my case on
OS X.)

I've tried opening up the .4DC from inside of the component and selecting
the .4DD right next to it before moving the component over to the host. No
help.

I've tried specifying .4DC in the USE DATABASE path, but that doesn't work
at all.

Suggestions appreciated.
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**