In Part 1 of this series, we discovered that using a Microsoft SQL Server (MS SQL or SQL Server) database will provide tools to handle large data sets, small data sets, complex data sets, dynamic data sets and even data that we share with other systems. But just what are those tools? How do I leverage SQL Server to processing these types of data with DriveWorks? What keywords should I put into my search engine to learn more More MORE? That’s what we’ll answer in this column.
Database. Just seeing the word can make people want to call a consultant. Luckily, I know where you can find one. (You can’t blame a guy for trying, right?) While DriveWorks provides a tremendous amount of rule driving functionality, when it comes to crunching raw data, the undisputed ruler of that domain is the database. Well, I’m here to spill the secrets and give you the basic concepts that you need to leverage Microsoft SQL Server (aka SQL Server aka MS SQL) for your DriveWorks data.
A large number of questions that you see in the DriveWorks forums (you do follow those, right?) all have to do with the interaction between DriveWorks and SOLIDWORKS. Most often, that question involves a DriveWorks user asking how to get the results from a SOLIDWORKS model generation to drive a DriveWorks specification. Whether that means using the mass properties that SOLIDWORKS calculates, a reference dimension from a sketch, Bill of Materials information, or an interference check, people want DriveWorks to run that model while the user is filling in their forms.
Those of you who are new to DriveWorks or new to the use of Specification Macros (“spec macros” as Glen Smith is keen to tell us all the cool kids call them) will not notice anything out of the ordinary when you first see the spec macros form in DriveWorks 16. I mean, you’re seeing it for the first time. But those seasoned veterans who have spent time pulling tasks from the toolbox are bound to be taken aback when seeing spec tasks in DriveWorks 16.
Before we can start troubleshooting anything, we need to first figure out what is wrong. Now I mean this in the most general way. Are we having a problem where the drawing is incorrect? Are we having a problem even getting a drawing to generate when we release? Are we even getting to the point where we can release? Is our computer even able to startup? If the problem is the last one, try turning it off and back on again.
The two biggest themes in DriveWorks 16 (DW16) seem to be 3D Interaction and CPQ. While DriveWorks has always been quite capable of serving all of the needs of the CPQ community, DriveWorks 15 introduced a CPQ “template” (such an inadequate term for as much as it does).
Well, it’s almost that time. The newest version of DriveWorks is in development now. Actually, the newest version is always in development, I suppose. But now, DriveWorks 16 is getting close to its release date.
OK, maybe “happy” isn’t really a term one would use when working with the SOLIDWORKS API. I’m not saying that the SOLIDWORKS API is bad, it just…well, it can be challenging at times. But if you insist that you NEED to write custom code (I find it rare that I need to if I use DriveWorks to its full potential), then you certainly can use DriveWorks and the SOLIDWORKS API together.
One of the greatest assets that Razorleaf can claim is a breadth of knowledge across industries and technologies. Recently, I had the opportunity to jump into something really fun and exciting, where you enter product details into a form and magically, models and drawings appear to suit your use case. I’m talking about DriveWorks design automation software. More importantly, I had the opportunity to work with industry expert, Paul Gimbel and learn some things you can only learn by working on real projects.
Tabular data is one of the foundations of the DriveWorks design rule. Rules generally fall into one of two categories: Calculations or Logic, or Lookups. Three. DriveWorks rules generally fall into one of THREE categories: Calculations, Logic or Lookups. The perennial favorites VLookup() and HLookup() join forces with DWVLookup() to allow DriveWorks architects the ability to store tables of static data, like material properties, available stock parts, and so on, and pull values from data for calculations or decisions.