PC SOFT

FOROS PROFESIONALES
WINDEVWEBDEV y WINDEV Mobile

Inicio → WINDEV 2024 → [WXxx] SQLServer Native Access
[WXxx] SQLServer Native Access
Iniciado por guest, 05,ago. 2015 15:35 - 4 respuestas
Publicado el 05,agosto 2015 - 15:35
Poll: SQL Server Native Access provides real added value

Hi,

For one of our customers we are requested to move one of our WebDev solutions from HFCS to SQLServer 2012.
Is there any specific reason to use the SQL Server Native Access solutions?

We are not using any direct bound tables, controls or anything from our web pages as all is OO class based and goes via a business layer first before being submit/fetched from the database. On the other hand we use blob fields (XML, HTML, Binary) intensively for this solution.
At first sight (as we dot use any RAD, SQL Server views, etc...) we have the impression that using oleDB should be sufficient to migrate our solution to SQL Server.

Apart of that there is also the cost impact:
Making a simple calculation would immediately account for 2400€ (One Dev/Test SQL Server, One Pre-Production SQL Server, One Production SQL Server) to have the migration done using SQL Server Native Access since we need a native access for all SQL servers although only one of them is the final end-user production environment.

So here's my question:
- Is there a real need to use the SQL Server native access?
- What are the advantages based on your experience over oleDB?
- We use hCommands in our OO db access layer but this seems to work fine using oleDB with SQL Server as well. Or are we missing some constraints here?
- Any other experience you guys would like to share? ...

Thanks in Advance,

Peter H.
Publicado el 05,agosto 2015 - 17:22
Hi

I try...

- Is there a real need to use the SQL Server native access?
Yes, it's fast and simple to use HCommands, and I've been using more than
3 yrs since sqlServer2012 (32/64 bits are good to go), deployment is simple.
- What are the advantages based on your experience over oleDB?
Never use oleDB as it's thick layer (I guess it's on top of odbc that works as
a simple wrapper), I meant the data packets are bulky esp. you have lots of
tables and rows, it is slow.
- We use hCommands in our OO db access layer but this seems to work fine using oleDB with SQL Server as well. Or are we missing some constraints here?
I think the native sqlClient 11 from microsoft does the job so makes oleDB works out but
I am not sure...

- Any other experience you guys would like to share? ...

For simplicity and fast access and that's the money you pay for, correct.
Pretty much I've been using wx as it's simple to deploy apps letting me
concentrate on business need and always give surprise to customers.


Cheers

King
Publicado el 05,agosto 2015 - 23:36
Hi Peter,

I use both native access and OLEDB with my WD 19 application and there are 2 main reasons why I'm pushing my newer clients to Native access.

1. It's faster. OLEDB is mostly adequate speed wise but I'm also putting clients up on a commercial server and I needed the increased speed to make that a viable solution (it's roughly 4x faster with native access)

2. Without Native access you don't get any of the nice WD data access notifications such as when 2 users open same record simultaneously and bump heads on save. In OLEDB this can cause crashes, with native access the user gets notified. Obviously this may not be a problem depending on how your app is coded but it it is still something to consider.

With that being said OLEDB was a workable solution and had I needed to I could have stayed with it.

Let me know if you have any other questions.

steve
Publicado el 06,agosto 2015 - 08:49
Hi Peter,

if you have 30Gb database and speed is your concern then put all your insert, update, delete in stored procedure and use oledb to call it .

using native access will make programming alot easier in WXxx but the trade off is slower.
Publicado el 06,agosto 2015 - 10:12
Hi,

in which concern is programming easier with native Access?

I use oledb (mainly because native Access is too expensive, would cost more than our app in most installations). Using queries and hx commands all work fine, what can be easier?
When I Need a query which cannot be done with query-editor, I use hexecutesql instead and create the query inside my code.

Any hints or ideas are welcome.

g

Erik