[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now

x
?
Solved

Move local views from one DBC to another

Posted on 2014-01-23
3
Medium Priority
?
589 Views
Last Modified: 2014-01-24
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
Comment
Question by:terrypba1
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
3 Comments
 
LVL 43

Assisted Solution

by:pcelba
pcelba earned 1000 total points
ID: 39805042
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
 

Author Comment

by:terrypba1
ID: 39805075
Sounds doable, but how about the forms with references to the views in their original database?
0
 
LVL 30

Accepted Solution

by:
Olaf Doschke earned 1000 total points
ID: 39805729
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.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Microsoft Visual FoxPro (short VFP) is a programming language with it’s own IDE and database, ranking somewhat between Access and VB.NET + SQL Server (Express). Product Description: http://msdn.microsoft.com/en-us/vfoxpro/default.aspx (http://msd…
I'd like to talk about something that is near and dear to my heart: build systems. Without them, building software is all about compiling locally, with software versions everywhere. It can be a mess. Today we are going to discuss building a small di…
This tutorial covers a step-by-step guide to install VisualVM launcher in eclipse.
This tutorial will introduce the viewer to VisualVM for the Java platform application. This video explains an example program and covers the Overview, Monitor, and Heap Dump tabs.
Suggested Courses

656 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question