No, they wouldn't without an SCONNECT first.

Does the data in LEADALL change frequently?  How is it maintained (i.e.,
when it is being maintained, is the user still connected first to LABOR?) 

If the data does not change frequently, consider SCONNECTing SALES, then
SATTACH LEADALL AS someothername, then PROJECT TEMPORARY LEADALL from that
other name, then SDISCONNECT SALES.  Now you have the data without needing
the DSN.

While you may have very good reasons to have these separate database, be
mindful that when accessing data via a DSN you will pay a performance
penalty.  

Emmitt Dove
Manager, Converting Applications Development
Evergreen Packaging, Inc.
[email protected]
(203) 214-5683 m
(203) 643-8022 o
(203) 643-8086 f
[email protected]


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Jim Belisle
Sent: Friday, May 15, 2009 8:52 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: DSNless connection

EMMIT,

Here are the two databases I use: LABOR & SALES.  The LABOR DB is my
primary database.  I created a Menu that is brought up with the DAT file
so they have access to all the forms they need.  

My sales people need to connect to one table (LEADALL) in the SALES
database on a regular basis.  This one table has all the leads and we
use the Indexed field (LEADCODE) to bring up the customer information
when they call for either a quote or want to order items.  As you can
see, the potential for being used constantly is very real. 

My question to you is this: If they SALES database is disconnected, will
they still be able to access the table (LEADALL) information?

Jim


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Emmitt
Dove
Sent: Friday, May 15, 2009 7:44 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: DSNless connection

Jim,

My advice is to only create the connection to the other database when
you
need it, then drop it as soon as you can.

As an example, we write inventory audit records into one of three
external
audit databases (dependent on the inventory type).  Those audits are
created
by triggers on the inventory tables.  In the stored procedure that is
the
trigger we do the SCONNECT, write the record(s), then SDISCONNECT.  This
avoids having umpteen people holding each of those audit databases open
constantly - they are only open when required.

You can SCONNECT the database, create your SATTACH, then SDISCONNECT;
the
attached table definition remains in your main database, so any other
structure elements that refer to it remain sound (i.e. views).

Why do it this way?  Each client has fewer resources in use (file
handles),
and with files on the server not held in an open state needlessly, there
are
just fewer things that can go wrong, fewer ways your databases can
become
corrupted through external means.  I've had situations where a client
machine crashed, and I had to reboot the file server to release the open
files.  Plus, since you don't have other users constantly connected to
the
target database, you can, if you need, connect it with MULTI OFF briefly
to
make a quick structure change, such as add an index.

Emmitt Dove
Manager, Converting Applications Development
Evergreen Packaging, Inc.
[email protected]
(203) 214-5683 m
(203) 643-8022 o
(203) 643-8086 f
[email protected]

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Jim
Belisle
Sent: Friday, May 15, 2009 6:04 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: DSNless connection

Razzak,

Thanks for the reply.  I did check all the settings as you suggested and
all looks good.  I read the documentation you suggested below as well
prior to setting up the ODBC connection.  I have tested it and it works
for me.  Hopefully there will be no "bugs" to work out.

Jim
  

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of A.
Razzak Memon
Sent: Thursday, May 14, 2009 11:44 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: DSNless connection

At 08:22 PM 5/14/2009, Jim Belisle wrote:

>RBASE is set up on each individual computer but the database is
>set up on a server.  If I put a DSN less connection to another
>RBASE database in the DAT file for when each user starts up, will
>that be a problem? Will there be a conflict in this scenario?
>We use the latest 7.6.

Jim,

Using System DSN or DNS-Less connection, you will have to make sure
that a full version of R:BASE 7.6 for Windows is installed using the
full installer that installs and configures the R:BASE 7.6 ODBC driver.

Use the ODBC Data Source Administrator panel to verify the properly
installed R:BASE 7.6 ODBC Drivers.

ODBC Data Source Administrator | Drivers ...

R:BASE 7.6 ODBC driver should be list as follows:

Name: R:BASE 7.6 Database Driver (*.rb1)
Version: 7.06.07.3xxxx
Company: R:BASE Technologies, Inc.
File: RBG76_32.DLL
Date: mm/dd/2009

Once the R:BASE 7.6 ODBC driver is installed and configured, you should
be able to use the DSN-Less connection to SCONNECT and SATTACH tables
as server or TEMPORARY table(s) from another R:BASE database.

Here is an example to automate the entire process:

-- Assure the connection of primary database
    IF (CVAL('DATABASE')) <> 'primrydb' OR (CVAL('DATABASE')) IS NULL
THEN
       CONNECT primrydb IDENTIFIED BY NONE
    ENDIF
-- Make sure that previously SATTACHed table is detached
    SDETACH ALL NOCHECK
-- Make sure that the previously DSN-Less Database is Disconnected
    SDISCONNECT ';Driver=R:BASE 7.6 Database Driver
(*.rb1);dbq=seconddb'
-- Now Connect the Database Using the DSN-Less Connection
    SCONNECT ';Driver=R:BASE 7.6 Database Driver (*.rb1);dbq=seconddb'
-- SAttach Table(s)
    SATTACH table1 AS ttable1 USING ALL
    SATTACH table2 AS ttable2 USING ALL
    SATTACH table3 AS ttable3 USING ALL
-- do what you have to do after SATTACHing R:BASE database tables
-- Prior to exiting the application, make sure that all SATTACHed
-- table(s) are detached and the DSN-Less Database is Disconnected
    SDETACH ALL NOCHECK
   SDISCONNECT ';Driver=R:BASE 7.6 Database Driver (*.rb1);dbq=seconddb'

For a technical document with further details, take a look at:

 From The Edge: http://www.razzak.com/fte/
Article: Using DSN-Less Connections in R:BASE

Very Best R:egards,

Razzak.


Reply via email to