Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 593
  • Last Modified:

Move local views from one DBC to another

I realized quite early in a major project the virtue of keeping views isolated in their own DBC, but nonetheless have ten or so views still in a DBC with data tables. These views are in a number of screen data environments, so I suspect it would be major surgery at this point to move these views to their own DBC? This application has been in use for four years now and I'd like to clean it up a bit for my successor.
Is there a reasonably simple way to move views to their own, new DBC, or do I bite the bullet and keep things as they are?
0
terrypba1
Asked:
terrypba1
2 Solutions
 
pcelbaCommented:
I would recommend to leave it to your successor... It is a great task in which you can test the deepness of her FoxPro knowledge. (Don't forget to backup everything... :-)

OTOH, it should not be so difficult to copy the view definition from one database to another.
Open the DBC file as a table by USE command and look for ObjectType = "View". This record is followed by several more records describing the view columns. You me recognize them by ParentID. You may copy these records to another database. You should also copy the connections used for views and maybe more objects (e.g. stored procedures if they are used).

You may also check Stonefield Database Toolkit if it would help to rearrange your databases: http://www.stonefield.com/sdt.aspx
0
 
terrypba1Author Commented:
Sounds doable, but how about the forms with references to the views in their original database?
0
 
Olaf DoschkeSoftware DeveloperCommented:
Set up a simple new project with a new database, a table and view using it. Set up a form using that view. Move that view, then try to use the form unchanged.

The best way to move views is use GENDBC and let it create a script regenerating the database schema, remove all code for tables and just leave the view definitions. The GENDBC script does not transfer any data, but views are merely a query definition. Add an OpenDatabase() function, where you open databases the views need during their definition, you may also need to define view parameters, especially when using view queries including macro substitution. Otherwise you're done. You can always enhance this generated script file and recreate the whole view dbc once there are changes.

Regarding the forms DE: The database references stored in the data environment are not mandatory, it's where VFP first looks for the data, but it also searches along SET PATH directories, besides, if a database is already open, VFP will use that  (I think, but what else should it do, if many tables come from the same database, opening it once is sufficient). So simply open all databases before using forms and they should work.

HACKSCX then may help to reconfigure the dataenvironment view objects, but indeed using the DE itself is something, which could be refactored: To be able to use databases in different locations - test, development and production data, for example - it's much easier to USE dbname!tablename in code (eg the OpenTables method of DEs) and open databases by a configuration file from the one or other location in main.prg or the init() event of an app class or a seperate database manager class. That also makes it easy to customize locations once there is a server migration, change of drive mappings, etc. IT departments need to be flexible, as the landscape of software changes faster and more than ever and needs of data consolidation or merging exist. Don't hardcode paths.

Bye, Olaf.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now