Oops, I misquoted myself (no pun intended). You are, of course, correct,
gsec does not like quotes. Just tried it on my home computer.
The XP machine where I'm having a hard time is in an auto-repair shop, so I
won't be able to try it tonight. Next time I get there I'll try it and let
you know
At 05:52 a.m. 20/06/2015, Karl Sandfort ksandf...@optimum.net
[firebird-support] wrote:
>I am new to Firebird. Was able to install on Windows 7 64-bit no problem.
>Immediately after install ran gsec user SYSDBA password firebird password> with no problems. However, on Windows XP Pro SP3,
Excellent explanation Ann, as always. Just one doubt:
After a cycle backup/restore: the restored database will have all the rows
with the new domain?
All columns with domain D_CURRENCY that were created with DECIMAL(9, 2) now
will be DECIMAL(18, 2) ?
Greetings.
Walter.
On Tue, Jun 16, 2015 at
I am new to Firebird. Was able to install on Windows 7 64-bit no problem.
Immediately after install ran gsec -user 'SYSDBA' -password '' with no problems. However, on Windows XP Pro SP3, I
downloaded the 32-bit exe installer. Install ran fine. When I try to run
gsec I get something like "User name
Hi all, some years ago I developed a web application based on Interbase,
Win98, PHP, Apache. During those yeas has been lightly updated with lase
release of software, now the we application (10 users) use the follow:
Microsoft Server 2012 (64bit)Apache 2.0PHP 5.4Firebird SQL 1.5 (3 databases,
2
>>For example in Java the default result set is forward only. If it doesn't
>>have rows, it will fetch a number (default is 400 in Jaybird), this is done
>>through a fetch. It will then serve requests for rows from the application
>>from this retrieved set of rows. When it needs more, it discards t
On Fri, 19 Jun 2015 14:48:44 +, "'Leyne, Sean'
s...@broadviewsoftware.com [firebird-support]"
wrote:
>> what is the proper way for copy data from big table to another database
>> if table is bigger then avaiable RAM and we need to do this in one
>> transaction?
>> You know if we do
>> SELECT *
On Fri, 19 Jun 2015 16:43:37 +0200, "Mark Rotteveel m...@lawinegevaar.nl
[firebird-support]" wrote:
> The proper way to do this is to execute a single query, and interleave
> fetching of rows from the source with inserting rows into the target.
That
> should work without consuming all memory as lo
> what is the proper way for copy data from big table to another database
> if table is bigger then avaiable RAM and we need to do this in one
> transaction?
> You know if we do
> SELECT * FROM SOURCE_TABLE - and table have e.g. 400 000 000 records
> then retrive it is impossible because of RAM
On Fri, 19 Jun 2015 15:20:39 +0200, "liviuslivius
liviusliv...@poczta.onet.pl [firebird-support]"
wrote:
> what is the proper way for copy data from big table to another database
> if table is bigger then avaiable RAM and we need to do this in one
> transaction?
> You know if we do
> SELECT * FROM
Hi,
I am not surprised about skip slowdown
I am talking about generic.
Something like "universal migrator".
I can imagine some trick with order by rdb$db_key but this solution can work
with Firebird/Interbase but is not avaiable for other servers.
If table key is not single field then this is no
On 19/06/15 14:20, liviuslivius liviusliv...@poczta.onet.pl
[firebird-support] wrote:
> SELECT FIRST 100 SKIP 0 * FROM SOURCE_TABLE <-we got 100 reads -> ok
> SELECT FIRST 100 SKIP 100 * FROM SOURCE_TABLE <-we got 200
> reads -> not ok
> SELECT FIRST 100 SKIP 200 * FRO
Hi,
what is the proper way for copy data from big table to another database
if table is bigger then avaiable RAM and we need to do this in one transaction?
You know if we do
SELECT * FROM SOURCE_TABLE - and table have e.g. 400 000 000 records
then retrive it is impossible because of RAM
but if
13 matches
Mail list logo
