On Mar 29, 11:26*pm, BillPedersen <wmapeder... (AT) gmail (DOT) com> wrote:

Bill,


Depending on the size of your database (doesn't sound very big at the
moment). With the following procedure there is no need to create a
dump file. IMPDP is very smart. You can even have it create the
tablespaces for you, although when moving to a completely new
platform, you should do that ahead of time unless you start up the
database with the parameter DB_FILE_NAME_CONVERT = '/dbs/t1/','DSA3:
[oradata]','dbs/t2/ ','DSA4:[oradata]' (note they are in comma
separated pairs)
and DB_CREATE_FILE_DEST = 'directory'. Oracle has gotten a lot better
at helping you move stuff about.

http://download.oracle.com/docs/cd/E...2.htm#i1006164

If you only have one schema (or many schema owners for that matter)
you can do the following:
Create database.
log in / as sysdba
[note this one connects to user SYSTEM using a SERVICE_NAME]
sql> create database link from_db CONNECT TO SYSTEM IDENTIFIED BY
systempassword
USING '(DESCRIPTION = (ADDRESS_LIST=(ADDRESS = (PROTOCOL = TCP)(HOST =
{HOSTIPADDRESS})(PORT = 1521))) (CONNECT_DATA =(SERVICE_NAME =
{SERVICENAME}))';

or
[note this one connects to schema owner using SID]
sql> create database link from_db CONNECT TO <schema_owner>
IDENTIFIED BY <password>
USING '(DESCRIPTION = (ADDRESS_LIST=(ADDRESS = (PROTOCOL = TCP)(HOST =
{HOSTIPADDRESS})(PORT = 1521))) (CONNECT_DATA =(SID = {SIDNAME}))';

select * from dba_directories;

exit sql.
=================================
impdp DIRECTORY=<SomeDirName from query above> NETWORK_LINK=from_db
schemas=<schema_owner>

Username: / as sysdba

OR

impdp DIRECTORY=<SomeDirName from query above> NETWORK_LINK=from_db
schemas=<schema_ownerA>,<schema_ownerB>
remap_schema=<schema_ownerA>:<schema_ownerC>
remap_tablespaces=<tablespaceA>:<tablespaceC>


SQL> select file_name from dba_data_files
2 ;

FILE_NAME
-------------------------------------------------------------------------------

C:\ORACLEXE\ORADATA\XE\USERS.DBF
C:\ORACLEXE\ORADATA\XE\SYSAUX.DBF
C:\ORACLEXE\ORADATA\XE\UNDO.DBF
C:\ORACLEXE\ORADATA\XE\SYSTEM.DBF
C:\ORACLEXE\ORADATA\XE\MYTABLESPACE

SQL> alter system set db_create_file_dest='C:\ORACLEXE\ORADATA\XE';

System altered.

SQL> create tablespace abc; <<<<NOTE: NO DATAFILE DEFINITION WAS
PROVIDED HERE.

Tablespace created.

SQL> select file_name from dba_data_files;

FILE_NAME
-------------------------------------------------------------------------------

C:\ORACLEXE\ORADATA\XE\USERS.DBF
C:\ORACLEXE\ORADATA\XE\SYSAUX.DBF
C:\ORACLEXE\ORADATA\XE\UNDO.DBF
C:\ORACLEXE\ORADATA\XE\SYSTEM.DBF
C:\ORACLEXE\ORADATA\XE\MYTABLESPACE
C:\ORACLEXE\ORADATA\XE\XE\DATAFILE\O1_MF_ABC_6S7J8 KB8_.DBF

6 rows selected.


[demonstrated using OracleXE (10.2.0.1) on windows - don't have the
patience to try and munge my VMS 7.3-2 system - besides not even sure
11gR2 would even install on it...]

On Mar 30, 3:55*pm, "Syltrem" <syltremz... (AT) videotron (DOT) ca> wrote:

Well, This is an interim solution. Part of the path to get an open
source application ported to Ingres.

Am VERY much aware of the Oracle debacle.

Regards,

I wanted to thank everyone for their help and suggestions.

As you mentioned going to file might make sense so I did that after I
could not quickly get the DATABASE LINK to work (many suggestions came
after I got that going).

Anyway, NOW, I have then entire application and database NATIVE on
OpenVMS.

So, I have an open source ERP application targetted at the SMB/SME
market place running on OpenVMS.

Yes, it is running against Oracle RDBMS, so the next challenge is the
big one, making it run against Ingres.

Regards,

Bill.

Bill:

# So, I have an open source ERP application targetted at the SMB/SME
market place running on OpenVMS.

Glad you are happy.

Not to be nasty ... but just how many real small medium or otherwise
companies are really going to take a stab at running an open source
ERP?

On Mar 31, 1:20*pm, John Hurley <hurleyjo... (AT) yahoo (DOT) com> wrote:
John, I think it will depend on how you position it. There are a fair
number of "nitch" environments where people have "rolled their own".
Usually someone has gotten unhappy with the what exists in an
application they are using and then start from SCRATCH - boy, I have
seen some of them. This is especially true in the retail
environment. So the ability to offer a "platform" where there is some
structure and a real database - may be of benefit.

In that regards I think it has potential.

In terms of someone picking it up from scratch, no.

Now, I do have a potential customer who has a retail shop but also is
developing a web presence. They have the continual issue of inventory
availability and knowing if something is still in the store - when it
is not and it is ordered from the web this becomes a problem.

With an ERP for an SMB with a POS interface as well as an interface to
the WEB then this issue goes away. Many small retailers who are
getting into this environment have a similar problem. Yes, there will
also be a need to change their procedures but if they are going to
succeed with eCommerce then they have to do that as well and it
getting their inventory under control they should then improve their
brick and mortar presence, too.

Bill.

On Mar 31, 8:37*pm, BillPedersen <wmapeder... (AT) gmail (DOT) com> wrote:
I would not say that it "goes away"... but it may reduce the frequency
of it occurring.

Playing Devil's advocate:
Sally goes into the store, sees the last item and places it in her
cart. Simultaneously Jane places the same item in her online cart.
Jane completes her transaction while at nearly the same time the clerk
scans the item from Sally's cart - item errors because there are no
more in stock. Now, what does the proprietor do? Tell Sally she
can't have what she has had in her cart for the last 30 minutes? Will
the system be able to handle the situation (over-rides etc...) And
will they be able to order another widget and back-order the online
transaction? etc. etc...

No need to respond, just food for thought...