Problem with the DAC provider.

At:-

http://groups.google.co.uk/group/microsoft.public.sqlserver.programmi...

Steve Dassin says:-

"If you are truely a beginner then your brain hasn't been filled with
crazy
glue yet.
For application development check out Dataphor. "

I am not yet proficient with SQL, and I'd like to avoid becoming
proficient with it. There are enough frustrated intellectuals banging
on about how inadequate it is for me to be virtually certain they're
right about Dataphor.

However, in this post:-

http://groups.google.com/group/comp.databases.theory/browse_thread/th...

Lauri says:-

" > I think an implementor would be better off using an SQL database

> underneath, and using their code layer in between to accomplish the
> "divorce" from the aspects of SQL that they disapprove of.

That is, in fact, the approach taken in a product called Dataphor
(see www.alphora.com). They have implemented a "D"-language (called
D4)
that translates into SQL and hence uses underlying SQLServer, Oracle
or DB2- DBMS'es as the engine.

It is, however, not a very easy mapping to do and you have to resort
to all sorts of unclean stuff to make it work...

regards,
Lauri Pietarinen"

and he's right. Like Lauri says, it aint easy.

The documentation is skeletal for the "DAC provider" and almost non
existent for the ADO provider, both of which I am trying to get
working. With the ADO provider I am trying both an untyped and typed
dataset grid view in a windows form.

I have been getting a few helpful nudges from people involved with or
using D4, but I need further help to get the providers working. Things
are getting so bad that I may soon be forced to learn SQL.

Anyone know if there are any suitable forums for support with this
apart from this one?

Below is an outline of the problem I am having with the DAC provider.

------------------------

I've previously managed to get the ADO parameters functioning
satisfactorily for an update statement, but am having difficulty doing
the same in the "DAC" provider.

Below is the code I use at run time:-

Private seymore As New Alphora.Dataphor.DAE.Client.DataSetParamGroup

Private jobid1 As New Alphora.Dataphor.DAE.Client.DataSetParam

...

DataView1.ParamGroups.Add(seymore)

seymore.Source = DataSource1

This gives me a stack overflow exception(?!).

---

When I add param groups to the paramgroups collection property of the
dataview at design time, and then

count them with

MsgBox(DataView1.ParamGroups.Count)

Or

MsgBox(DataView1.ParamGroups.Contains(0))

it responds as if they don't exist.

---

Atdesign time, it tells me in the dataparamgroup datasource property
"object reference not set to instance of object"

Even when I have set it to the only datasource, when I close the
collection and then return to that property of that dataparamgroup, it
gives this same message.

---

DataView1.ParamGroups.Add(seymore)

'seymore.Source = DataSource1

MsgBox(DataView1.ParamGroups.Count)

MsgBox(DataView1.ParamGroups.Contains(seymore))

seymore.Params.Add(jobid1)

also gives the "object reference" exception even immediately after
recognising the seymore object as a member of the paramgroups
collection.

I get the feeling I'm overlooking something horribly simple. :(

------------------------

Help!

Steve B.

Update Statements in a DataView

Hi Steve,

I'm not sure I understand what you are trying to do with the parameters, but let me start with a piece by piece:

> DataView1.ParamGroups.Add(seymore)
> seymore.Source = DataSource1

> This gives me a stack overflow exception(?!).

Based on the way this is configured, that is what would happen. There is supposed to be a better error message (something like 'circular data source'), but this is an invalid configuration. The Source of a ParamGroup optionally identifies the DataSource for the values of the parameters. In this case, DataSource1 is connected to DataView1, so the reference is circular. To put it another way, you cannot parameterize DataView1's expression with values from DataView1's result set.

> When I add param groups to the paramgroups collection property of the
> dataview at design time, and then count them with

> MsgBox(DataView1.ParamGroups.Count)

> Or

> MsgBox(DataView1.ParamGroups.Contains(0))

> it responds as if they don't exist.

Unfortunately, ParamGroups were introduced after the components were made 'designable' in Visual Studio, so it's likely that those properties simply won't work very well at design time. Future versions may improve design-time support for these controls, but I would recommend using these properties programatically for now.

Which brings me to the main question I have, why are you trying to use parameters. The DataView is a fully functional data set, capable of issuing the appropriate update statement itself. So all you really need to do is something like this:

DataView1.Edit()
DataView1.Fields("job_desc").AsString = "Test1"
DataView1.Post()

Unfortunately, this fails in this case because of the identity defined on the jobs table in the pubs database (SQL Server won't let you update identity columns). The reason this is happening in this case though is because the entire update is occurring within an Application transaction. If you turn that off with this statement:

DataView1.UseApplicationTransactions = false

prior to calling the Edit, then that problem won't happen because the Dataphor server knows that only the job_desc column changed, so it will issue an update statement that only updates that column.

I know this doesn't help you use parameter groups at design-time, but I hope it helps get past some of the issues you're seeing.

Regards,
Bryn Rhodes
Database Consulting Group LLC