A place to discuss the virtues of xCase
Newest version 8.0 [March 2006]
Home Page: http://www.xcase.com/
xCase is most useful for initially designing structures, relations and indexes, and for documenting database schema changes during development. While some can and do use Xcase to write and maintain VFP views, there are better tools available. It can also be used to maintain database schema changes (it's data files can be placed under source control), and can be used to produce database change scripts. However, most will probably work directly with the database, and in the case of SQL Server, create their own scripts. After the initial design, you'll likely use Xcase to document the database as it goes into production, and again periodically during development, and again as the database is modified during the maintenance phase.
Also, for ongoing maintenance of SQL Server databases, take a look at SqlCompare from Red Gate Software
- Steve Sawyer
xCase is great for initially designing structures, relations and indexes. The minute you start to view design is the minute you export your DBC to PRG code and put xCase on the shelf until the next new project.
In this developer's opinion (take it for its worth), the view designer is very cumbersome and non-intuitive. The view designer interface is not easy to understand. VFP views are not able to be reverse-engineered (which is sometimes the meat of the DBC) and because of this you are forced to use the xCase interface.
The thing that really irked me was the fact that there was no view reporting. xCase can generate some fantastic reports of tables, relations and indexes. You would think with all the information stored in DBF format, Resolution could generate some reports about the views.
Latest version can reverse-engineer VFP Views.
Other than view maintenance, I think xCase is a great product. And considering it is the only ERD program available for VFP (I don't see ERWIN being modified anytime soon) that I know of, it should be a tool in everyone's development arsenal. -- Larry Miller
Once Lisa Slater Nicholls showed me how to use the view designer in xCase I began to see its power: it is an incredible piece of work, in the way it handles pathes between entities. I couldn't imagine designing complex views without it. -- Hank Fay
I´m Using xCase for all my projects. Tech Support is excellent. Program id growing everyday, and now I must use xCase as my view designer. It makes excellent joins, and it´s more intuitive than a View Editor that simply, does not work with more than 2 tables. -- Miguel Angel Hernaiz
I have a question: Cross model domains - we want to use the same domains in our SQL models and our VFP DBC model. Experience any gotchas?
My experience with it centers around reverse-engineering MS-SQL Server 6.5 databases. I don't see why it COULDN'T do what you describe, as long as you don't use VFP-specific function calls in triggers or SP's. -- Dan LeClair
One of the really, really nice features of xCase is that the ER data is saved in dbf's, allowing us to use that data in a variety of ways. In my case, I wanted to move the data information, augmented with additional attributes, into the Visual Pro Matrix data dictionary. I ended up doing a bit more, creating a developer's product. xCase 2 VPM. -- Hank Fay
think the easiest way to deal with this, in xcase, is as follows. (By the way, I use the 16 bit GUID's instead of the 32 bit, unless I'm hitting SQL, or going to at some point, but this is easy to change to that).
Open an xcase model.
Click on Dictionary then Domains
Define a domain (like a type) as follows
The VK is just the name I chose. It could be anything, however, it needs to be consistent with the next change. The global means that all xCase models will have access to this field. The GUID(16) is the VFE function that will be used to generate the value.
Now that you have defined that domain(type), tell xCase to automatically stuff it into all new FoxPro files. So,
Edit xcase.ini (in the xcase directory. Copy the original to another file, so you can get at it later, when you decide you hate the way I do things).
Go to the [Numerators] section.
Change the VFP line to the following:
What this means is, all key names will end up with a k followed by the file name (ie. customer file has key kCustomer). The type will be gotten from the Domain VK, in the case a c(16). The last bit tells it that foreign key names will match (ie, the field in invoice that holds the customer key, will be called kCustomer). This is my preference, it is originally something else.
Other people use cCustomer_ID, and various other things, but I find the above to be more logical, and you don't run the risk of loosing the ID in long field names...
Lastly, make sure you chose the auto numerator feature when you created your project.
For developers who prefer integer primary keys, they are easier to set up in the latest version of xCase (7.4). With your VFP model open
- Select Options | Preferences from the menu
- Select the Numerators tab
- Set "PK Name" to i%sPK - this will result in iTableNamePK fields
- Set "Pk Domain" to Integer or Integer (autoincrement)
- Set "FK Name" to i%sFK for auto-named "iTableNameFK" fields
I think the documentation could use some work, but I use this tool all the time. In my situation I have a multi-company set of DBC's. Manually I can keep them all in sync by renaming my DBC and changing the paths in the Dictionary/DBC and Free Tables form. I'm sure there is an automated way to do this, just haven't gotten around to it.
Category Third Party Products Category Data Modeling
( Topic last updated: 2006.03.31 01:18:37 PM )