| Subject | RE: [firebird-support] External File Construction |
|---|---|
| Author | Epstein, Ed |
| Post date | 2004-02-10T17:24:32Z |
There are no other servers. Only a single IB Server. The Front-end is
parsing CSV files that are supplied to it, and it is constructing the
appropriate script files or attempting to insert them directly via
ADO-OLEDB. I have tried to overwrite the file that is referenced externally
only to get an access denied error. I will try that again and see what
happens.
Edwin Epstein
privileged and confidential and protected from disclosure.
If the reader of this message is not the intended recipient, or an employee
or agent responsible for delivering this message
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer.
-----Original Message-----
From: Alan McDonald [mailto:alan@...]
Sent: Monday, February 09, 2004 5:57 PM
To: firebird-support@yahoogroups.com
Subject: RE: [firebird-support] External File Construction
sending files to remote servers and importing into those remote servers.
That's why I ask about replication - you can replicate in real time from one
server to all other (distributed) servers without this need for
export/email/import cycle.
If that's no good you could try exporting processed records to external
files (structure defined once at the main server, then you send out these
external files, get your remote admins to place them next to the gdb file
and execute a script of n lines (where n is the bumber of tables) which
basically does
INSERT INTO INTERNAL_TABLE(FIELDLIST) VALUES SELECT * FROM EXTERNAL TABLE;
This will be the fastest way to transport and import the records.
It also requires that the external files are defined at each location. They
can be overwritten each time you send new records out. You would also need a
mechanism to recognise that the import has completed and not import the same
file more than once.
Personally I prefer real time solutions.
Alan
Yahoo! Groups Links
parsing CSV files that are supplied to it, and it is constructing the
appropriate script files or attempting to insert them directly via
ADO-OLEDB. I have tried to overwrite the file that is referenced externally
only to get an access denied error. I will try that again and see what
happens.
Edwin Epstein
> Continuity Partners Inc.CONFIDENTIALITY NOTICE: The information contained in this message may be
> 2753 S. Highland Dr.
> Suite 1010
> Las Vegas, Nevada 89109
> (702) 851-7850 Ext. 247
> eepstein@...
>
privileged and confidential and protected from disclosure.
If the reader of this message is not the intended recipient, or an employee
or agent responsible for delivering this message
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer.
-----Original Message-----
From: Alan McDonald [mailto:alan@...]
Sent: Monday, February 09, 2004 5:57 PM
To: firebird-support@yahoogroups.com
Subject: RE: [firebird-support] External File Construction
> 1) scripting file created by the front-end and sent to the IB Server to beOK so there ARE other servers? You are exporting from one central server,
> executed via a DOS shell using the ISQL program. Uses simple Insert
sending files to remote servers and importing into those remote servers.
That's why I ask about replication - you can replicate in real time from one
server to all other (distributed) servers without this need for
export/email/import cycle.
If that's no good you could try exporting processed records to external
files (structure defined once at the main server, then you send out these
external files, get your remote admins to place them next to the gdb file
and execute a script of n lines (where n is the bumber of tables) which
basically does
INSERT INTO INTERNAL_TABLE(FIELDLIST) VALUES SELECT * FROM EXTERNAL TABLE;
This will be the fastest way to transport and import the records.
It also requires that the external files are defined at each location. They
can be overwritten each time you send new records out. You would also need a
mechanism to recognise that the import has completed and not import the same
file more than once.
Personally I prefer real time solutions.
Alan
Yahoo! Groups Links