Thursday, February 22, 2007

The ADO prepared property.

Today I was playing with some ADO queries and I stumble one more time with the famous prepared property. Based on the BDS help it says:

Description Set Prepared before calling the Open method to specify whether ADO prepares the command used to create the dataset’s recordset. If Prepared is set to true and the dataset component is connected to a data store, ADO prepares the command before executing it. If Prepared is set to false, ADO does not prepare the command. The default value of Prepared is false.

Now, after a bit of research I found this interesting article on the msn dev network.

The important part is here:

Prepared property

In theory, the Prepared property was designed to reduce work on the server by pre-compiling ad hoc queries so subsequent executions would use a temporary stored procedure instead of repeating the compile phase each time the query is executed. However, this is not the case with ADO's implementation—keep reading.

Since ODBC was invented some years ago, SQL Server has gotten much smarter—it now knows how to leverage existing (in cache) compiled query plans. That is, once you execute a query from ADO (or by any means), SQL Server constructs a query plan, saves it in the procedure cache, and executes it. When the query is done, SQL Server marks the query plan as "discardable" but leaves it in memory as long as it can. When another identical (or close-enough) query comes in, which is very likely in systems running multiple clients, SQL Server simply re-uses the cached plan. This saves a significant amount of time and greatly improves scalability. It makes SQL Server actually run faster as more users are added, assuming they're doing about the same things with the same set of queries.

ADO and its ODBC and OLE DB data providers know about this strategy, and in most cases they execute sp_executesql to take advantage of this feature. However, this puts the Prepared property in a quandary. It insists on creating temporary stored procedures, but the data providers insist on using sp_executesql. The result? Chaos. I describe what happens a little later when executing Command objects is discussed.

My recommendation for the Prepared property: forget it—at least for SQL Server. For other providers, set up a trace that shows exactly what's going on—what the server is being asked to do.

Now this is extremely interesting for me, specially the sp_executesql part, DataSnap indeed wraps every call in a "sp_executesql" so we are good there, now about using the prepared property, I will do more research on it, but for now, I will leave it alone. :P



Wednesday, February 21, 2007

Code Rage 2007!!!



Go to the virtual conference from CodeGear called CodeRage 2007.

It includes Delphi, Java, Php and even Ruby sessions with an All-Star set of speakers.

For more information go here!

Now, I think that everybody knows about it, but just in case...



Delphi 2007 for Win32 is available now! and in a well expected move, the new Delphi for Php makes his debut. A visual IDE for PHP using the same VCL structure that we all know and learn to love.

Thursday, February 15, 2007

More Delphi News!!

Wow the information is in pieces everywhere.. check the following segments of "information" said by Michael Swindell (Delphi VP - CodeGear) that appeared on the borland newgroups:

"
c) Delphi Product line - we are realigning development plans and approaches
to focus on the individual native code Win32 editions (Pro/Ent) of the
products first, then fold them into an updated Studio that will include the
.NET updates. Architect and Turbo's would fall out of the Studio releases.
The Turbo's eds will become more lightweight in the process as well. The
majority of Delphi (and C++Builder) developers are focused on native code
development - so we are aligning our releases and timeframes accordingly.
Moving everything into monolithic Studio releases had some positive effects
but also some drawbacks that came thru in customer feedback. Having to wait
for the "all personalities" was not ideal for C++ and Delphi native
developers, who had either no or minimal interest or need for .NET. It
spread attention more thinly across the products, so we are changing the
approach so that during the year Delphi native developers have focused
specific attention in a product release, same with C++ developers, and .NET
developers. This approach actually worked quite well in past lives with
Delphi and C++Builder - although the complaint years ago from C++Builder
developers was that they had to wait 6mo to a year for the latest Delphi
features... which is something that we aim not to fall into. "


Then in addtion pay attention to the new "ALL DELPHI" intention with the new pricing model and SKU's:

"
Turbo Delphi Explorer -> Turbo Delphi "better" -> Delphi Pro -> Delphi Ent

same as above for C++

then Studio Pro/Ent/Arch incl both C++ and Delphi and .NET and Win32

Turbo Pro New and Delphi Pro Upgrades similar price level. So it will be
recommended in order to keep the feature level go to Delphi Pro as the
upgrade. This is a tuning of the editions. We released the Turbos with the
intention that we would see what worked and what didn't and make some
changes in 2007 to improve.

> How is this going to be handled?
> Or is the "lightweight" reference to reduced resource demands rather
> than reduced features?

lighter weight - in features and resource and download image

in general we have 12yrs of sku's editions pricing for Win32, .NET, Pascal,
C++, Linux, and more to work out the best "model" that cleans things up, and
focuses our energy (development, packaging, and marketing) on the things
that are most important to existing customers and enables us to put Delphi
into more developers hands than ever. So there will be some things that we
do that will seem like we're undoing something we've done or said
previously, or changing a position on something previously stated or
published. Some things will probably seem crazy or sacrilege, but we plan to
grow Delphi, and to do that requires a little bit of house cleaning and
tuning. We'll probably make a few mistakes in the process, but the goal is
long term. Delphi and C++Builder have helped millions of developers, we
think the Delphi way of developing can benefit millions more developers -
and we want to bring the Delphi ideas and approach to everyone we can. The
CodeGear difference is that we're going to take some risks and try new
things, but we won't be doing it at the expense of our customers. "

It is expected a Delphi release by the end of March maximum!.




Wednesday, February 14, 2007

Delphi 2006 new RollUp fix !

Already! more good news!

New Delphi hot fix rollup:

Here!

It fixes the following issues (long):


Version 10.0.2558.35231

===============================================================================

BDS2006 Update 2 Hotfix 10a

This Hotfix applies to:

Product: Borland Developer Studio
Version: 2006
Update level: Update 2
Editions: Professional, Enterprise, Architect, Turbo
Languages: English, German, French, Japanese


Description of updates that are included in this hotfix:

This hotfix contains a fix for the source code editor. If the source
code contained
accented or international characters, viewing the code as text and then
returning to
the file format would erroneously reset the source code to default ANSI,
thereby losing
the accented or international characters.

The source code (.pas) might become corrupt, especially if the source
code was
larger than 64K and if the accented or international characters occurred
only after
the intial 64K.

Quality Central Tracking Number(s): 32936, 32844
Internal Tracking Number(s): 241502, 241552

Copyright 2006, Borland Software Corporation. All rights reserved.

===============================================================================

BDS2006 Update 2 Hotfix 10b

This Hotfix applies to:

Product: Borland Developer Studio
Version: 2006
Update level: Update 2
Editions: Professional, Enterprise, Architect, Turbo
Languages: English, German, French, Japanese


Description of updates that are included in this hotfix:

This fix incorporates the following enhancements and fixes:

- The enhancement suggested in QC Report # 26063 to improve the SOAP
deserialization of multiref objects and arrays.

- The WSDL importer now exposes elements with 'maxOccurs="unbounded"'
as arrays and the SOAP runtime handles the conversion to and from XML.
(QC #35512)

- TXSDateTime (and other TXSxxxx types) can now be serialized as XML
attributes (QC #10969)

- The WSDL importer now handles schemas included or imported by the
schema
embedded within a WSDL.

- An uninitialized TXSDateTime will default to the value of
"0001-01-01T00:00:00" instead of
"1899-12-30T00:00:00.000".

- The WSDL published by Delphi applications was updated to be more
compliant with
the style expected by WSDL2Java importers.

- The SOAP runtime properly restores enumerated identifiers that were
renamed
because of conflicts with Delphi keywords or directives.

Quality Central Tracking Number(s): QC #26063, QC #33512, QC #10969
Internal Tracking Number(s): RAID #241798, #241801, #242796

Copyright 2006, Borland Software Corporation. All rights reserved.

===============================================================================

BDS2006 Update 2 Hotfix 10c

This Hotfix applies to:

Product: Borland Developer Studio
Version: 2006
Update level: Update 2
Editions: Professional, Enterprise, Architect, Turbo
Languages: English, German, French, Japanese


Description of updates that are included in this hotfix:

Removes the length limitation on search paths. Specifying a large
number of deeply
nested directories could exceed an internal limit.


Internal Tracking Number(s): RAID #242012

Copyright 2006, Borland Software Corporation. All rights reserved.


===============================================================================

BDS2006 Update 2 Hotfix 10d

This Hotfix applies to:

Product: Borland Developer Studio
Version: 2006
Update level: Update 2
Editions: Professional, Enterprise, Architect, Turbo
Languages: English, German, French, Japanese


Description of updates that are included in this hotfix:

This hotfix addresses the issue of Korean characters in the code editor
initiating
unwanted cold folding and causing access violations.

Quality Central Tracking Number(s): 35357
Internal Tracking Number(s): 242562

Copyright 2006, Borland Software Corporation. All rights reserved.


===============================================================================

BDS2006 Update 2 Hotfix 10e

This Hotfix applies to:

Product: Borland Developer Studio
Version: 2006
Update level: Update 2
Editions: Professional, Enterprise, Architect, Turbo
Languages: English, German, French, Japanese


Description of updates that are included in this hotfix:

This hotfix contains a fix for the VCL form designer to allow the F1
help key
to query the help system for the selected component.

Copyright 2006, Borland Software Corporation. All rights reserved.


===============================================================================

BDS2006 Update 2 Hotfix 10f

This Hotfix applies to:

Product: Borland Developer Studio
Version: 2006
Update level: Update 2
Editions: Professional, Enterprise, Architect, Turbo
Languages: English, German, French, Japanese


Description of updates that are included in this hotfix:

This fix enables all COM\ActiveX menu items and wizards that are in the
Pro version of Delphi.

Copyright 2006, Borland Software Corporation. All rights reserved.

Happy Birthday Delphi!! woo hoo

Today is a big day! Delphi's bday.

Yup, 12 years ago Delphi came up to the market, the coolest and greatest development language on earth came to our lives.

You will see lots of posts on the newgroups and on popular blogs about this, you can read about Delphi Spacely and Delphi Astro, Delphi expansions into Vista and Ajax :).

I will be adding links that talk about the celebration on this post during the day, so there ya go:

Marco CantĂș

Friday, February 09, 2007

A new jmission!!

Well, lots of changes lately, so I haven't being able to blog for a bit.

So, let me fix that.

First, I am now living in Vancouver, yup, work takes you everywhere so now I'm on a mission to make a successful company even more successful.

I'm working again with the mighty Java during the day and during the night as usual on the super powerful Delphi. I'm working lately a lot with 3 different middle tier framework architectures, on the java side, JBoss, on the Delphi side with KbmMW and RemObjects SDK.

It is extremely interesting to see how the concepts of each of those frameworks just repeat themselves on each platform. I still cant understand why things are so not friendly on the Java side, all the functionality is there but there is a huge gap to present things in an easy way to the user.

I like Delphi cause it allows you to easily jump into something and slowly depending on your needs you can look under the hood and get into the complexity of it. Java (Eclipse, even with lots of plug ins) stills presents a very aggressive learning curve. I'm pretty sure the results at the end are fantastic, but still always seems like things are being done the hard way.

There is a big standardization thanks to Sun, XML is everywhere, but is because of those that presenting all these standards to the eye of the developer is still as plain as a text file.

Today I asked a couple of java guys what were the plug ins or they use to develop their methods and other interfaces on JBoss remote services, the answer: we don't, we go into plain code.

No service builder, no nice drop and use components.

I think that is ok, but, I'm aware their are plug ins that make your life easier (Lamboz-JBoss), but at the end of the day the java guys remain like their Linux counterparts, completely old schoolers. They produce great pieces of software but the productivity level is in my opinion low. Two companies and large teams behind their products had showed me this.

My goal is to become good in Java and try to find all the required tools to get as close as I can to the speed of development of Delphi, will I be able to achieve this, maybe not, but it will certainly be interesting to try.

Anyway, I am using a great mix of RemObjects and KbMmW.

I am behind a new idea that I want to implement on the kind of platforms I develop. RemObjects is very easy to use, and provides a great DataSnap integration pack, it is completely object oriented and their plug in system to attach different channels and message packages formats is done in the RAD way, meaning its as visual as it can be. Now, KbMmw presents the fastest memory table in town, plus it shows a great maturity in their framework (Kim has years behind this baby, so, experience talks).

Having licenses for both and using their high points is helping me to build a super scalable beast. I hope to see and post the results soon.

In the meanwhile see ya all later.