Sorry! Thanks Stephen even!
-Original Message-
From: ProfoxTech On Behalf Of Chris Davis
Sent: Sunday, 01 December 2019 14:30
To: profoxt...@leafe.com
Subject: RE: SQL Dump
Thanks Russell I will get on google/youtube tonight and look into this , thanks
for the heads up
-Original
Thanks Russell I will get on google/youtube tonight and look into this , thanks
for the heads up
-Original Message-
From: ProfoxTech On Behalf Of Stephen Russell
Sent: Sunday, 01 December 2019 13:48
To: profoxt...@leafe.com
Subject: Re: SQL Dump
That sounds like an ETL job that I would
er 2019 16:08
> To: profoxt...@leafe.com
> Subject: Re: SQL Dump
>
> What incorrect answers these were.
>
> IN the DB you made in SQL Server you can import the data at SSIS speed.
>
> Rt click on the DB in the DB pane. Tasks and Import Data.
>
> >From there you tell it to use V
...@leafe.com
Subject: Re: SQL Dump
For the purposes of a daily backup as a failsafe or what?
On 11/30/2019 2:51 PM, Chris Davis wrote:
> Thanks everyone for all the ideas and advice, I will give them a try.
>
> Effectively what I am trying to create is a way to replicate a VFP DBC to a
> SQL Da
For the purposes of a daily backup as a failsafe or what?
On 11/30/2019 2:51 PM, Chris Davis wrote:
Thanks everyone for all the ideas and advice, I will give them a try.
Effectively what I am trying to create is a way to replicate a VFP DBC to a SQL
Database daily.
...@leafe.com
Subject: Re: SQL Dump
What incorrect answers these were.
IN the DB you made in SQL Server you can import the data at SSIS speed.
Rt click on the DB in the DB pane. Tasks and Import Data.
>From there you tell it to use VFP data via your oledb engine. From
>there
it will make all
What incorrect answers these were.
IN the DB you made in SQL Server you can import the data at SSIS speed.
Rt click on the DB in the DB pane. Tasks and Import Data.
>From there you tell it to use VFP data via your oledb engine. From there
it will make all tables and indexes from VFP and
On Fri, 29 Nov 2019, at 2:46 PM, MB Software Solutions, LLC wrote:
> Another great tip! Dropping the indexes before adding records
Well, it's not dropping them per se, with MSSQL you can just disable them
temporarily which is much easier.
ALTER INDEX myindex ON mytable DISABLE
ALTER INDEX
Another great tip! Dropping the indexes before adding records is a
proven speed tip too if you can do it and then just re-add afterwards.
On 11/29/2019 4:48 AM, Alan Bourke wrote:
Is this a one-off data take on, or an ongoing requirement?
If you have the ability to do it, you might see an
Is this a one-off data take on, or an ongoing requirement?
If you have the ability to do it, you might see an improvement by disabling all
*non-clustered* indexes on the target SQL Server tables before doing your
inserts, and then re-enabling them afterward.
--
Alan Bourke
alanpbourke
Great idea, Frank...and easier too!!
On 11/28/2019 12:57 PM, Frank Cazabon wrote:
You could dump it to excel or CSV and then do an import in SQL
On 28 November 2019 12:55:01 GMT-04:00, Chris Davis
wrote:
Hi All
Is there any tricks I am missing which would speed up a dump of a VFP
table
You could dump it to excel or CSV and then do an import in SQL
On 28 November 2019 12:55:01 GMT-04:00, Chris Davis
wrote:
>Hi All
>
>Is there any tricks I am missing which would speed up a dump of a VFP
>table into a SQL table.
>
>I have predifined by SQL statement something like this
>
Hi Chris,
Well, it does have to iterate through each record. If no memo fields, I
guess you could construct multi-line inserts using TEXTMERGE but that's
probably no better for speed. Is this going across a network? How wide
are the tables? Can you post the code so we can see if there's
13 matches
Mail list logo
