Chuck Edge

Visual Basic is a language (and, in weak parlance, a standalone development environment) Visual Studio is a suite which among other things supports VB development.

Given a set of steppers, it is always 100 percent true. The pricing model for IC fabrication is almost identical to that in the printing and press industry.

Excellent. Dog's on the right track, but some quick questions. When you say the company wants to "separate the data into two separate database," are you talking about mirroring or actually splitting data? Basically Dog is assuming that data shared between the two DBs evolves in lock stop.

Then there's no need for herme3 to handle this issue. The company clearly has someone else who can. This is really getting into the weeds. Same thing for the whole injection point.

That should fiber space, not bundle space, right? And since [imath]f[/imath] from X to Y is surjective, a fiber bundle is the set of inverses back from Y to X, right? The way I see it, if space Y is a point or contracted to a point and [imath]f[/imath] is surjective, then there's only one fiber back to X. This gives us a product space [imath]f \circ f^-1[/imath] that's trivial. I have no idea where I'm going with this.

Splits always reduce predictive power. Whether or not it's rubbish depends on how granular your split and how much the variable you're splitting varies.

I imagine you start with an equation of state with temperature as a parameter and build a more complex model around it with things of interest to paleoclimatologists as inputs. But good question.

I'm no mathematician, but as I understand it given spaces X and Y and a surjective map [imath]f[/imath] from X to Y, a fiber is an inverse map [imath]f^{-1}[/imath] back to X. If X is contractible, then it is homotopy equivalent to a point, in which case the bundle space has only one element and is therefore trivial. Am I on the right track?

SQL is a separate language, specifically the language to manipulate information stored in a relational database. You can use a PHP library like PEAR DB, PDO, or ADOdb to abstract out a good amount of SQL coding you'd otherwise have to do with other hooks, but you should still understand some basic SQL (and the syntax associated with the specific database management system ) in order to perform queries that can't be covered by your typical create, retrieve, update and delete operations. Also, some clarifications on previous points raised in the thread. Transact is an SQL syntax specific to Microsoft's SQL Server. A number of commercial and a few open source DB's offer a procedural extension to their SQL implementations. However, you'll first want to tell us out what you're using. Also, it sounds like you're going to build an application over an existing schema (the layout of data and its relations). You'll want to figure out exactly how that schema looks (or at least the part relevant to your task) before moving forward. That said, if you want to develop quickly with the shallowest learning, follow Pangloss' suggestion and use Visual Web Developer. For one, you won't have worry too much about injection. You shouldn't have to anyway, and you definitely don't need to read a couple of articles to get the idea that you should escape any strings derived from user input before doing any mutating operations.