Stored Procedure vs. SQL As Datasource

Hi all.

Just a quick question about some behaviours I am seeing with a datawindow
I've developed.

I was handed an existing report for an application and asked to make it more
efficient and run faster.  The existing report is an external that derives
its data from a SQL Server 7 stored procedure and it ran like a pig.  The
stored procedure creates a temp table, selects data into it, and then
supplies that data to the external.

Not being a huge fan of stored procedures to begin with, I rewrote the SQL
for the report's data just as a SQL Select in a freeform dw and now the
report runs fast, at least 3 times faster than the existing report.

Now, here's the question.  I know that a lot of people tout SPs as a
transaction and processing saver since all of the work is done on the server
but if the general case is that a straight Select will run so much faster
why would anyone bother to use them other than in the case that a straight
Select would be so complex that the SP makes sense from a conceptual point
of view?

Just curious about this.  My place of employment likes to use SPs and if I
can have some evidence that they aren't "better" then that would be cool.

TIA,
Erin

PS:  I've using PB6.5.1 and MS SQL Server 7.


0
Erin
7/5/2002 12:35:59 PM
sybase.powerbuilder.datawindow 28057 articles. 5 followers. Follow

6 Replies
1277 Views

Similar Articles

[PageSpeed] 56

Stored procedures are used for other reasons. For example, changes can be
made to the sp logic with needing to redeploy the application.

Poorly designed stored procedures can explain the performance you describe.
If you are able to write a SQL statement that yields the equivalent results
as the stored procedure that is 3 times faster, you may need to investigate
the design and implementation of the stored procedure. You also need to
consider where the performance is being lost. In your example, the TEMP
table is a contributor to the problem. However, the use of an external
datawindow (assuming I read the last sentence of the 2nd paragraph
correctly) may be the bigger problem. Have you tried using the SP as a
direct source to a datawindow?

/ck

"Erin Peterson" <erin.peterson@gnb.ca> wrote in message
news:sy5U0FCJCHA.1020@forums.sybase.com...
> Hi all.
>
> Just a quick question about some behaviours I am seeing with a datawindow
> I've developed.
>
> I was handed an existing report for an application and asked to make it
more
> efficient and run faster.  The existing report is an external that derives
> its data from a SQL Server 7 stored procedure and it ran like a pig.  The
> stored procedure creates a temp table, selects data into it, and then
> supplies that data to the external.
>
> Not being a huge fan of stored procedures to begin with, I rewrote the SQL
> for the report's data just as a SQL Select in a freeform dw and now the
> report runs fast, at least 3 times faster than the existing report.
>
> Now, here's the question.  I know that a lot of people tout SPs as a
> transaction and processing saver since all of the work is done on the
server
> but if the general case is that a straight Select will run so much faster
> why would anyone bother to use them other than in the case that a straight
> Select would be so complex that the SP makes sense from a conceptual point
> of view?
>
> Just curious about this.  My place of employment likes to use SPs and if I
> can have some evidence that they aren't "better" then that would be cool.
>
> TIA,
> Erin
>
> PS:  I've using PB6.5.1 and MS SQL Server 7.
>
>


0
Chris
7/5/2002 1:04:00 PM
Just to add to Chris' comments a bit:

Temp tables are not always the culprit, sometimes they are the savior.  I 
rewrote a stored proc that was taking 40+ seconds to use a temp table and 
got the performance down to 3 seconds.

The bottom line for any piece of SQL is to see what is necessary to 
optimize its execution.

In your particular case, you could have left the call in a stored proc and 
simply replaced the existing logic with your single SQL statement.  This 
would pretty much satisfy everyone's needs.  Then, as Chris pointed out, 
simply make the stored proc the data source of a dw and you're done.

steve 
[TeamSybase]

>>Stored procedures are used for other reasons. For example, changes can be 
made to the sp logic with needing to redeploy the application. Poorly 
designed stored procedures can explain the performance you describe. If you 
are able to write a SQL statement that yields the equivalent results as the 
stored procedure that is 3 times faster, you may need to investigate
the design and implementation of the stored procedure. You also need to 
consider where the performance is being lost. In your example, the TEMP 
table is a contributor to the problem. However, the use of an external 
datawindow (assuming I read the last sentence of the 2nd paragraph 
correctly) may be the bigger problem. Have you tried using the SP as a 
direct source to a datawindow?

/ck

"Erin Peterson" <erin.peterson@gnb.ca> wrote in message
news:sy5U0FCJCHA.1020@forums.sybase.com...
> Hi all.
>
> Just a quick question about some behaviours I am seeing with a datawindow
> I've developed.
>
> I was handed an existing report for an application and asked to make it
more
> efficient and run faster.  The existing report is an external that 
derives
> its data from a SQL Server 7 stored procedure and it ran like a pig.  The
> stored procedure creates a temp table, selects data into it, and then
> supplies that data to the external.
>
> Not being a huge fan of stored procedures to begin with, I rewrote the 
SQL
> for the report's data just as a SQL Select in a freeform dw and now the
> report runs fast, at least 3 times faster than the existing report.
>
> Now, here's the question.  I know that a lot of people tout SPs as a
> transaction and processing saver since all of the work is done on the
server
> but if the general case is that a straight Select will run so much faster
> why would anyone bother to use them other than in the case that a 
straight
> Select would be so complex that the SP makes sense from a conceptual 
point
> of view?
>
> Just curious about this.  My place of employment likes to use SPs and if 
I
> can have some evidence that they aren't "better" then that would be cool.
>
> TIA,
> Erin
>
> PS:  I've using PB6.5.1 and MS SQL Server 7.
>
>

<<
0
Steve_Katz_
7/5/2002 3:14:33 PM
If you create simple DW to represent one or two tables you simply use SQL 
Query or Quick select to get the source for your DW. It's really good and 
fast way of design. But often your logic is so difficult and you need to 
use SP as a DW's source. I'm not sure I could make the most of my DWs 
without SP by the PB's embeded SQL.
Another case of using SP is the security. Having SP you can asign rights to 
call it to some users but not any. So I often use SPs.
As for fast of execution: In general it's big part of exploration. For 
exsample SP works as you need but was designed not competently. So to 
optimize it you need to rewrite your SP.
0
Dmitry_Kovtun
7/7/2002 8:44:51 AM
There are many reasons why to use SPs.
Some important among them.

1) Performance 1. Even relatively short SPs are faster
    than the corresponding SQL statement because of the precompiled
    nature of an SP. If you manage to write an SQL statement
    which performs faster than the corresponding SP then replace
    the SQL statement in SP to this better one and you will have
    the same or better performance.

2) Performance 2. You save on the network trip from the client
    to server. Almost always the call string is shorter then
    the equivalent SQL statement.

3) Performance 3. If your task requires multiple steps (several
    SQL statements) then you will save more on the network trip
    mentioned above plus you will not transfer massive volumes
    of data between client and server.

4) Security. In order to perform data manipulation you do not
    need to grant table access (all levels). You will grant
    execute on the corresponding SPs. It has one more advantage.
    Nobody will access tables from ANY tools (ISQL, third party
    tools) or applications and destroy data integrity.

5) All validation and business rules are in one place (recall that
    not all of them can be declared and even implemented in triggers)
    so all applications accessing these tables comply with the same
    rules. Besides if you need to change them it will be done in
    one place which simplify maintenance and guarantee consistency.

6) Predictability. If your DB server is running in cost based
    optimization mode then your SQL statements performance can vary
    in broad range depending on available statistics which is often
    unacceptable especially for OLTP DBs. Precompiled SPs use the same
    execution plans which calculated at the compile time.

It is necessary to point out that there are some other considerations
related to multitier application which shift role of SP to middle
tier - application server. But still it is ONE place for the DB access.




Erin Peterson wrote:
> Hi all.
> 
> Just a quick question about some behaviours I am seeing with a datawindow
> I've developed.
> 
> I was handed an existing report for an application and asked to make it more
> efficient and run faster.  The existing report is an external that derives
> its data from a SQL Server 7 stored procedure and it ran like a pig.  The
> stored procedure creates a temp table, selects data into it, and then
> supplies that data to the external.
> 
> Not being a huge fan of stored procedures to begin with, I rewrote the SQL
> for the report's data just as a SQL Select in a freeform dw and now the
> report runs fast, at least 3 times faster than the existing report.
> 
> Now, here's the question.  I know that a lot of people tout SPs as a
> transaction and processing saver since all of the work is done on the server
> but if the general case is that a straight Select will run so much faster
> why would anyone bother to use them other than in the case that a straight
> Select would be so complex that the SP makes sense from a conceptual point
> of view?
> 
> Just curious about this.  My place of employment likes to use SPs and if I
> can have some evidence that they aren't "better" then that would be cool.
> 
> TIA,
> Erin
> 
> PS:  I've using PB6.5.1 and MS SQL Server 7.
> 
> 

0
Vladimir
7/7/2002 8:33:43 PM
All good points.
Disadvantages:
1. SPs are DBMS-specific, so if you need to support multiple DBMSs or you
need to change DBMS then you're in for a lot of work.
2. Re point (1) below.  The precompiled nature of an SP can often slow down
performance if you're not careful.  The execution plan is determined using
the data that was there when the SP was compiled.  The data at runtime could
be very different and require a different execution plan, and this could
slow things down enormously.  For instance, compile with no data in the
database and the plan will call for full table scans, run it with 1,000,000
rows, you'll still get a full table scan.  So you need to make sure that for
any SPs where the underlying data is quite dynamic, the SPs are recompiled
regularly.

S.

--
All views expressed in this message are my own and not necessarily those of
my employer


"Vladimir Gendler" <vgendler@socal.rr.com> wrote in message
news:3D28A5A7.1060407@socal.rr.com...
> There are many reasons why to use SPs.
> Some important among them.
>
> 1) Performance 1. Even relatively short SPs are faster
>     than the corresponding SQL statement because of the precompiled
>     nature of an SP. If you manage to write an SQL statement
>     which performs faster than the corresponding SP then replace
>     the SQL statement in SP to this better one and you will have
>     the same or better performance.
>
> 2) Performance 2. You save on the network trip from the client
>     to server. Almost always the call string is shorter then
>     the equivalent SQL statement.
>
> 3) Performance 3. If your task requires multiple steps (several
>     SQL statements) then you will save more on the network trip
>     mentioned above plus you will not transfer massive volumes
>     of data between client and server.
>
> 4) Security. In order to perform data manipulation you do not
>     need to grant table access (all levels). You will grant
>     execute on the corresponding SPs. It has one more advantage.
>     Nobody will access tables from ANY tools (ISQL, third party
>     tools) or applications and destroy data integrity.
>
> 5) All validation and business rules are in one place (recall that
>     not all of them can be declared and even implemented in triggers)
>     so all applications accessing these tables comply with the same
>     rules. Besides if you need to change them it will be done in
>     one place which simplify maintenance and guarantee consistency.
>
> 6) Predictability. If your DB server is running in cost based
>     optimization mode then your SQL statements performance can vary
>     in broad range depending on available statistics which is often
>     unacceptable especially for OLTP DBs. Precompiled SPs use the same
>     execution plans which calculated at the compile time.
>
> It is necessary to point out that there are some other considerations
> related to multitier application which shift role of SP to middle
> tier - application server. But still it is ONE place for the DB access.
>
>
>
>
> Erin Peterson wrote:
> > Hi all.
> >
> > Just a quick question about some behaviours I am seeing with a
datawindow
> > I've developed.
> >
> > I was handed an existing report for an application and asked to make it
more
> > efficient and run faster.  The existing report is an external that
derives
> > its data from a SQL Server 7 stored procedure and it ran like a pig.
The
> > stored procedure creates a temp table, selects data into it, and then
> > supplies that data to the external.
> >
> > Not being a huge fan of stored procedures to begin with, I rewrote the
SQL
> > for the report's data just as a SQL Select in a freeform dw and now the
> > report runs fast, at least 3 times faster than the existing report.
> >
> > Now, here's the question.  I know that a lot of people tout SPs as a
> > transaction and processing saver since all of the work is done on the
server
> > but if the general case is that a straight Select will run so much
faster
> > why would anyone bother to use them other than in the case that a
straight
> > Select would be so complex that the SP makes sense from a conceptual
point
> > of view?
> >
> > Just curious about this.  My place of employment likes to use SPs and if
I
> > can have some evidence that they aren't "better" then that would be
cool.
> >
> > TIA,
> > Erin
> >
> > PS:  I've using PB6.5.1 and MS SQL Server 7.
> >
> >
>


0
Simon
7/8/2002 9:46:20 AM
Agree.

Some additions.

1. SPs in almost all major DBs (MS is exception) can be written
    in Java. It will minimize (but not eliminate) some work
    during migration. Still "native" SPs are faster from DBs
    accessibility point of view.

2. As usual to solve the problem of different DBs with different
    SQL flavors one additional layer may be introduced. Now is
    popular to use three (and more) tiers solutions for this and
    many other purposes.




Simon Caldwell [TeamSybase] wrote:
> All good points.
> Disadvantages:
> 1. SPs are DBMS-specific, so if you need to support multiple DBMSs or you
> need to change DBMS then you're in for a lot of work.
> 2. Re point (1) below.  The precompiled nature of an SP can often slow down
> performance if you're not careful.  The execution plan is determined using
> the data that was there when the SP was compiled.  The data at runtime could
> be very different and require a different execution plan, and this could
> slow things down enormously.  For instance, compile with no data in the
> database and the plan will call for full table scans, run it with 1,000,000
> rows, you'll still get a full table scan.  So you need to make sure that for
> any SPs where the underlying data is quite dynamic, the SPs are recompiled
> regularly.
> 
> S.
> 
> --
> All views expressed in this message are my own and not necessarily those of
> my employer
> 
> 
> "Vladimir Gendler" <vgendler@socal.rr.com> wrote in message
> news:3D28A5A7.1060407@socal.rr.com...
> 
>>There are many reasons why to use SPs.
>>Some important among them.
>>
>>1) Performance 1. Even relatively short SPs are faster
>>    than the corresponding SQL statement because of the precompiled
>>    nature of an SP. If you manage to write an SQL statement
>>    which performs faster than the corresponding SP then replace
>>    the SQL statement in SP to this better one and you will have
>>    the same or better performance.
>>
>>2) Performance 2. You save on the network trip from the client
>>    to server. Almost always the call string is shorter then
>>    the equivalent SQL statement.
>>
>>3) Performance 3. If your task requires multiple steps (several
>>    SQL statements) then you will save more on the network trip
>>    mentioned above plus you will not transfer massive volumes
>>    of data between client and server.
>>
>>4) Security. In order to perform data manipulation you do not
>>    need to grant table access (all levels). You will grant
>>    execute on the corresponding SPs. It has one more advantage.
>>    Nobody will access tables from ANY tools (ISQL, third party
>>    tools) or applications and destroy data integrity.
>>
>>5) All validation and business rules are in one place (recall that
>>    not all of them can be declared and even implemented in triggers)
>>    so all applications accessing these tables comply with the same
>>    rules. Besides if you need to change them it will be done in
>>    one place which simplify maintenance and guarantee consistency.
>>
>>6) Predictability. If your DB server is running in cost based
>>    optimization mode then your SQL statements performance can vary
>>    in broad range depending on available statistics which is often
>>    unacceptable especially for OLTP DBs. Precompiled SPs use the same
>>    execution plans which calculated at the compile time.
>>
>>It is necessary to point out that there are some other considerations
>>related to multitier application which shift role of SP to middle
>>tier - application server. But still it is ONE place for the DB access.
>>
>>
>>
>>
>>Erin Peterson wrote:
>>
>>>Hi all.
>>>
>>>Just a quick question about some behaviours I am seeing with a
>>
> datawindow
> 
>>>I've developed.
>>>
>>>I was handed an existing report for an application and asked to make it
>>
> more
> 
>>>efficient and run faster.  The existing report is an external that
>>
> derives
> 
>>>its data from a SQL Server 7 stored procedure and it ran like a pig.
>>
> The
> 
>>>stored procedure creates a temp table, selects data into it, and then
>>>supplies that data to the external.
>>>
>>>Not being a huge fan of stored procedures to begin with, I rewrote the
>>
> SQL
> 
>>>for the report's data just as a SQL Select in a freeform dw and now the
>>>report runs fast, at least 3 times faster than the existing report.
>>>
>>>Now, here's the question.  I know that a lot of people tout SPs as a
>>>transaction and processing saver since all of the work is done on the
>>
> server
> 
>>>but if the general case is that a straight Select will run so much
>>
> faster
> 
>>>why would anyone bother to use them other than in the case that a
>>
> straight
> 
>>>Select would be so complex that the SP makes sense from a conceptual
>>
> point
> 
>>>of view?
>>>
>>>Just curious about this.  My place of employment likes to use SPs and if
>>
> I
> 
>>>can have some evidence that they aren't "better" then that would be
>>
> cool.
> 
>>>TIA,
>>>Erin
>>>
>>>PS:  I've using PB6.5.1 and MS SQL Server 7.
>>>
>>>
>>
> 
> 

0
Vladimir
7/8/2002 2:07:45 PM
Reply:

Similar Artilces:

stored procedure as datasource for datawindow (MS SQL vs. Oracle)
Hi, I used to prepare stored procedure (in MS SQL Server) as data source for every datawindow like: create sp_... .... begin ... select col_01, col_02, ... from ... where ... ... end I need to implement the same in Oracle EE 7.3. But it is not even possible to compile such code in PL/SQL stored procedure (error says there has to be an into clause). So the question: can PL/SQL stored procedure be datasource for datawindow in PB? If so, what syntax. Thanks for any help. Martin Helmich, Empire s.r.o. ...

HELP! Direct execution of SQL in Powerbuilder vs using stored procedures
I'm debugging a powerbuilder process for my company but I unfortunately don't have much pb experience... Here's the facts: Powerbuilder 5.0 Microsoft SQL Server 6.5 on Windows NT 3.51 The program opens a cursor on a dataset and then loops through the rows. For each row it must interrogate the data and then perform some appropriate action upon the database. The dataset is approx 500,000 rows and the job is taking a very long time (60 hours +) to complete. My task is to reduce the execution time. I've noticed that the code is calling a function for each itera...

PowerBuilder 9.0.1 crashes when datawindow SQL calls stored procedures
We use PowerBuilder 9.0.1 on MS Windows XP Professional, Intel Pentium III 900 MHz, 256 MB RAM, 29 GB free disk space, with Oracle 9.2.0.1.0 and Oracle 8.7.1. We installed the 9.0.1 patch on Sept. 9. On the surface, all looked fine. On Sept. 10, we had to change a query behind a datawindow, and PB would keep crashing and shutting down everytime we tried to open the SQL view (syntax mode). It turns out that that datawindow is not the only one that has that problem. Almost all our other datawindows suffers from the same problem. In particular, the problem almost always hits...

Powerbuilder datawindow + stored procedure
database ASA 7 When we build a datawindow in powerbuilder we choose the table and the columns to build it. There is also the possibility to build a datawindow from a stored procedure. Is a stored procedure running faster because the database remembers the execution plan? Thanks Eric "ontsnapt" <ontsnapt@hotmail.com> wrote: > database ASA 7 > > When we build a datawindow in powerbuilder we choose the table and the > columns to build it. There is also the possibility to build a datawindow > from a stored procedure. > > Is a stored...

SQL Stored Procedure Issue
This is the Stored Procedure below ->  SET QUOTED_IDENTIFIER ON GOSET ANSI_NULLS ON GO /****** Object:  Stored Procedure dbo.BPI_SearchArchivedBatches    Script Date: 5/18/2007 11:28:41 AM ******/if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[BPI_SearchArchivedBatches]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)drop procedure [dbo].[BPI_SearchArchivedBatches]GO /****** Object:  Stored Procedure dbo.BPI_SearchArchivedBatches    Script Date: 4/3/2007 4:50:23 PM ******/ /****** Object:  Stored Proc...

datawindow with stored procedure datasource
When I try to create a new datawindow in PB 8.00 with a stored procedure as its source, the System Procedures check box is disabled and I cannot select it as the source. But if I go to the database profile I can see the list of system stored procedures. Any help would be greatly appreciated. Thanks, Sandee What database? On Fri, 3 May 2002 16:56:18 -0400, in powersoft.public.powerbuilder.datawindow <sandee> wrote: >When I try to create a new datawindow in PB 8.00 with a stored procedure as >its source, the System Procedures check box is disabled and I canno...

SQL Stored Procedure to MySQL Stored Procedure Conversion
Hi, I am trying to convert a stored procedure written for sql to one that will work in mysql. I understand that I have to set the variables as IN , but I don't know what to do with the rest of the code. The following is the sql stored procedure that I am trying to convert to msql stored procedure: CREATE PROCEDURE Register_User (@userName Varchar(50), (@PassWord Varchar(50), (@FirstName Varchar(50), (@LastName Varchar(50) ) AS IF EXISTS(SELECT u_ID FROM User_ID Where u_UserName=@UserName) RETURN -1 ELSE INSERT User_ID( u_User...

Stored Procedure in SQL of Datawindow
I would like to call a stored procedure in the SQL of a datawindow and have my alias column equal to the return value of my stored procedure. I cannot use a nested datawindow for the SP because we are passing the data back and forth from the server to the client in a tab delimited string and the string will not contain the data from the nested datawindow. Is what I want to do valid? I tried a number of different combinations in the SQL, but I couldn't figure out the correct syntax if there is one. exec sp_balance as my_column sp_balance as my_column my_column = exec sp_bala...

How to convert Sql Server Stored Procedures into Oracle Stored Procedures
Hi All, I am migrating from sql server2000 to oracle. I have moved all table into oracle manually. Now I need to move stored procedure. I don't know how to convert sql server stored procedure into oracle stored procedure form. Is there any tool which will convert directly. Please some one help me. Thank you.    Hi there,Please use the tool bellow, which does the job you want. http://www.swissql.com/products/sqlserver-to-oracle/sql-server-to-oracle.html thanks sharp guy...

sql count using stored procedure withing stored procedure
I have a stored procedure that among other things needs to get a total of hours worked. These hours are totaled by another stored procedure already. I would like to call the totaling stored procedure once for each user which required a loop sort of thing for each user name in a temporary table (already done) total = result from execute totaling stored procedure Can you help with this Thanks It would be easier if you can change the stored procedure into a function. Once you do that, the total can be calculated easily with something like thisSelect Sum(dbo.CalculateHours(User...

MS SQL stored procedures inside another stored procedure
Hi,  Do you know how to write stored procedures inside another stored procedure in MS SQL.   Create procedure spMyProc inputData varchar(50) AS  ----- some logical    procedure spMyProc inputInsideData varchar(10) AS    --- some logical   ---  go ------- What exactly are tou trying to do? ***********************Dinakar NethiLife is short. Enjoy it.*********************** Like Function, you can have one function inside another another function. Function1 () {    Function2() } How about store procedure ? spProc1 { &n...

Using stored procedures as a datasource for a datawindow
Hi, I have inherited an application where the previous developer has put a lot of funtionality into stored procedures. The database object (tables, procedures, etc.) have been copied to a development database for me to work in. Anyway, I went to create a new stored procedure based data window. I got to the part where Powerbuilder presents me with a list of available procedures and I got a datawindow error saying "Item <list of stored procedures in db> does not pass validation test." and the list of stored procedures does not get populated. I thought at fi...

Stored procedure VS Sql inline
Hi.I want developed project that must  3-tire architects so i need info about stored procedure vs sql inline.please help me????????  Try starting here. Website Design Darlington - http://mdssolutions.co.ukhttp://lessthandot.com - Experts, Information, Ideas & Knowledgehttp://aspnetlibrary.com - An online resource for professional ASP.NET developersPlease remember to click "Mark as Answer" on this post if it helped you Hi payandeh, What you need to do is READ ALOT! I'll give you a head start of where to look: www.google.be http://weblogs.asp.net/f...

stored procedure vs. sql statements
How do you know what to use for accessing the db?  thanks. It simply depends on the requirement.Stored proc has its own advantages like security, performance, executing multiple sql statements, maintaining transactions, etc.What exactly is your requirement? Based on that we can arrive at a conclusion.  Depends on your situation. Stored procs are more efficient and they can be used to restrict access (you can give a user permission to a sproc, but not to a table). Sql statements are more flexible as you can change them without meddling with the database. If you don't know h...

Web resources about - Stored Procedure vs. SQL As Datasource - sybase.powerbuilder.datawindow

Datasource - Wikipedia, the free encyclopedia
A DataSource object has properties that can be modified when necessary. For example, if the data source is moved to a different server, the property ...

Inverness Graham Acquires DataSource
Inverness Graham , a lower middle market private equity firm headquartered in suburban Philadelphia, has acquired DataSource , a print supply ...

SmartGlance for iPad for iPad on the iTunes App Store
Read reviews, get customer ratings, see screenshots, and learn more about SmartGlance for iPad on the App Store. Download SmartGlance for iPad ...

Chaitanya Pandit (@chaitanyapandit) on Twitter
Sign in Sign up To bring you Twitter, we and our partners use cookies on our and other websites. Cookies help personalize Twitter content, tailor ...

Data source - Wikipedia, the free encyclopedia
... Data source A data source is any of the following types of sources for (mostly) digitized data: a database in the Java software platform, datasource ...

2ndQuadrant - PostgreSQL expertise from specialists with a source code level understanding of RDBMS ...
PostgreSQL expertise from specialists with a source code level understanding of RDBMS PostgreSQL Planets Gabriele’s PlanetPostgreSQL Gianni’s ...

Tagged entries for CLOUD COMPUTING
Alan Williamson's output as a Java Champion, Blog-City Architect, BlueDragon Creator, Author, Speaker and Internet Guru

Private equity deals
... of biometric identity management systems, applications and services. www.crossmatch.com Inverness Graham Investment has acquired DataSource ...

C# C Sharp and Tutorials on C# Friends.com
Learn the c# langauge to build web applications using our online tutorials with live demos. Participate in our forums and learn from others. ...

JavaScript UI Library, Ajax Components & HTML5 Framework - DHTMLX
DHTMLX offers a rich JavaScript library, UI components & HTML5 mobile framework. Build impressive web apps for both desktop and mobile devices. ...

Resources last updated: 1/4/2016 10:08:10 AM