Free Tables to DBC - Is behaviour different? 
Author Message
 Free Tables to DBC - Is behaviour different?

I have an application (which I don't have source to). I need to update
external tables in real time as changes are made. The application has
been implemented with Free Tables.  I propose to add the tables to a DBC
and use the triggers (INSERT, UPDATE and DELETE) to update external
databases through ODBC.

In principle only, is if the free tables are put into a DBC will there
be any problems with existing code or any issues which may need
addressing.



Wed, 07 Mar 2001 03:00:00 GMT  
 Free Tables to DBC - Is behaviour different?
Darren:

    This is a good idea in theory, but adding a Free table to a DBC will
alter the table header; hence rendering it unusable in the other
application--the one you don't have the source code.  The difficult part
comes in when an update occurs in the Free table your new application must
be able to respond and update the external data source--am I right?

    At the moment, all I can think of is processing the Free tables in a
batch process.  Perhaps copying the Free tables and processing them; doing
this in a continuous event.  Suppose you were to create a DBC and tables
with the same structure as the Free tables.  Open up the Free tables in your
new application and scan for any record changes; then add the same changes
to your DBC tables. Your (INSERT, UPDATE and DELETE) of the DBC will take
care of the external databases through ODBC.  All you need is some primary
key in the Free tables to do this.

    This is just one idea, maybe someone else can add to this.

--Paul

Quote:

>I have an application (which I don't have source to). I need to update
>external tables in real time as changes are made. The application has
>been implemented with Free Tables.  I propose to add the tables to a DBC
>and use the triggers (INSERT, UPDATE and DELETE) to update external
>databases through ODBC.

>In principle only, is if the free tables are put into a DBC will there
>be any problems with existing code or any issues which may need
>addressing.



Wed, 07 Mar 2001 03:00:00 GMT  
 Free Tables to DBC - Is behaviour different?
Do you know if the other application is written in VFP?  If it is not then
you would probably have problems.  The other issues are if the
other application sends out updates and potentially overwrites or changes
the table.

-myron kirby-
Independent Consultant

===========================

Quote:

>I have an application (which I don't have source to). I need to update
>external tables in real time as changes are made. The application has
>been implemented with Free Tables.  I propose to add the tables to a DBC
>and use the triggers (INSERT, UPDATE and DELETE) to update external
>databases through ODBC.

>In principle only, is if the free tables are put into a DBC will there
>be any problems with existing code or any issues which may need
>addressing.



Thu, 08 Mar 2001 03:00:00 GMT  
 Free Tables to DBC - Is behaviour different?
Paul,

Thanks for your input. I have placed the tables in a DBC and am able to update
the view via ODBC. As far as I can see the application works fine and the remote
tables are updated. I understand that the table header is changed however this
only has the effect of making the application aware of the DBC. (In that the DBC
is opened along with the table - it certainly doesn't make it unusable!)

The idea of batch processing is one I pondered and it just isn't an option for a
variety of reasons.

I personally can't think of any reason why existing code would not work
correctly if free tables were placed in a DBC. I was just wondering if anybody
else had any thoughts on wheter any issues existed that I was unaware of.

Darren

Quote:

> Darren:

>     This is a good idea in theory, but adding a Free table to a DBC will
> alter the table header; hence rendering it unusable in the other
> application--the one you don't have the source code.  The difficult part
> comes in when an update occurs in the Free table your new application must
> be able to respond and update the external data source--am I right?

>     At the moment, all I can think of is processing the Free tables in a
> batch process.  Perhaps copying the Free tables and processing them; doing
> this in a continuous event.  Suppose you were to create a DBC and tables
> with the same structure as the Free tables.  Open up the Free tables in your
> new application and scan for any record changes; then add the same changes
> to your DBC tables. Your (INSERT, UPDATE and DELETE) of the DBC will take
> care of the external databases through ODBC.  All you need is some primary
> key in the Free tables to do this.

>     This is just one idea, maybe someone else can add to this.

> --Paul


> >I have an application (which I don't have source to). I need to update
> >external tables in real time as changes are made. The application has
> >been implemented with Free Tables.  I propose to add the tables to a DBC
> >and use the triggers (INSERT, UPDATE and DELETE) to update external
> >databases through ODBC.

> >In principle only, is if the free tables are put into a DBC will there
> >be any problems with existing code or any issues which may need
> >addressing.



Fri, 09 Mar 2001 03:00:00 GMT  
 Free Tables to DBC - Is behaviour different?
Myron,

Yes the other app is written in VFP5.  I don't think there is a problem in
what I propose, I was just wondering if concept of placing the free tables in
DBC would have any effect on the functionality of existing code, given that no
changes are made to the table structures and no RI or Stored procedures are
added to the DBC .. save and except the code on the triggers for the relevant
tables which will always return .T. and only update views of remote data.

Darren

Quote:

> Do you know if the other application is written in VFP?  If it is not then
> you would probably have problems.  The other issues are if the
> other application sends out updates and potentially overwrites or changes
> the table.

> -myron kirby-
> Independent Consultant

> ===========================

> >I have an application (which I don't have source to). I need to update
> >external tables in real time as changes are made. The application has
> >been implemented with Free Tables.  I propose to add the tables to a DBC
> >and use the triggers (INSERT, UPDATE and DELETE) to update external
> >databases through ODBC.

> >In principle only, is if the free tables are put into a DBC will there
> >be any problems with existing code or any issues which may need
> >addressing.



Fri, 09 Mar 2001 03:00:00 GMT  
 Free Tables to DBC - Is behaviour different?
Darren,

As long as the primary software does not update the DBC on you
I believe that you should be able to add it to a DBC and add your
stored procedure.  The only gotcha's I can think of are if the
primary application is using multiple databases or updates
the DBC, or has a process that re-creates the table.

-myron kirby-
Independent Consultant

===========================

Quote:

>Myron,

>Yes the other app is written in VFP5.  I don't think there is a problem in
>what I propose, I was just wondering if concept of placing the free tables
in
>DBC would have any effect on the functionality of existing code, given that
no
>changes are made to the table structures and no RI or Stored procedures are
>added to the DBC .. save and except the code on the triggers for the
relevant
>tables which will always return .T. and only update views of remote data.

>Darren


>> Do you know if the other application is written in VFP?  If it is not
then
>> you would probably have problems.  The other issues are if the
>> other application sends out updates and potentially overwrites or changes
>> the table.

>> -myron kirby-
>> Independent Consultant

>> ===========================

>> >I have an application (which I don't have source to). I need to update
>> >external tables in real time as changes are made. The application has
>> >been implemented with Free Tables.  I propose to add the tables to a DBC
>> >and use the triggers (INSERT, UPDATE and DELETE) to update external
>> >databases through ODBC.

>> >In principle only, is if the free tables are put into a DBC will there
>> >be any problems with existing code or any issues which may need
>> >addressing.



Fri, 09 Mar 2001 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Free Tables vs DBC

2. DBC vs. Free Tables in ODBC

3. .dbc vs. free tables

4. Free tables vs dbc

5. Set relation problems between DBC and free tables

6. dbc VS Free tables

7. Performance of Free tables compared to within a DBC

8. How to import hundreds of free table to one DBC

9. dbc vs free table

10. Inconsistent behaviour of VFP7 app on different machines

11. Different behaviour of executable

12. Browse Behaviour Different FPW vs VFP

 

 
Powered by phpBB® Forum Software