[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

WinCE How to run ruby on an iPAQ

David Maslen

10/13/2003 10:29:00 AM

I'm a new user of Ruby, but so far, I'm impressed and wanting to find
every opportunity to practice and learn more.

When I discovered the WinCE port in the source distribution of 1.8, I
thought terrific, now I can install ruby on my iPAQ and test things
out whenever I get a quiet moment.

While I don't have access to the tools to compile ruby for the pocket
pc, a google search turned up the binaries on a Japanese
site. Unfortunately there were no instructions in English, and I can't
really work out how to use ruby on my iPAQ.

Could somebody point me to some English documentation, or perhaps just
summarise the basic usage?

Is it as simple as writing a script and adding a bang path (#!) to the
top of it?

7 Answers

Mark Rae

10/5/2009 8:07:00 PM

0

"George Lee" <GeorgeLee@discussions.microsoft.com> wrote in message
news:432DEC4A-B503-4CCB-94E8-7C6CDCD69AA7@microsoft.com...

[please don't top-post]

>>> How do you read/write multivalued fields in Access 2007 with ADO.NET C#?
>>
>> http://tinyurl.c...
>
> For the following code, the DAO approach would be to create another
> recordset
> based on the parent and loop through it. Is there an ADO equivalent?
>
> DataSet ds = new DataSet();
> myAdapter.Fill(ds);

Not sure what you mean - that's ADO.NET...


--
Mark Rae
ASP.NET MVP
http://www.m...

Jesse Houwing

10/5/2009 9:23:00 PM

0

* Mark Rae [MVP] wrote, On 5-10-2009 22:06:
> "George Lee" <GeorgeLee@discussions.microsoft.com> wrote in message
> news:432DEC4A-B503-4CCB-94E8-7C6CDCD69AA7@microsoft.com...
>
> [please don't top-post]
>
>>>> How do you read/write multivalued fields in Access 2007 with ADO.NET
>>>> C#?
>>>
>>> http://tinyurl.c...
>>
>> For the following code, the DAO approach would be to create another
>> recordset
>> based on the parent and loop through it. Is there an ADO equivalent?
>>
>> DataSet ds = new DataSet();
>> myAdapter.Fill(ds);
>
> Not sure what you mean - that's ADO.NET...
>
>

The query syntax can be found here:
http://office.microsoft.com/en-us/access/HA1014929...

When doing a select, you'll get all the values that were in the
multivalued fields separated by ;.

You will have to split them manually if you want to use them for a data
binding scenario. There is no multi-valued field datatype that you can
select for the column in a dataset.

I'd recommend using a separate table instead of multi-valued fields.
They're a kind of poor-mans-solution for database design. You won't be
able to upgrade the database to any other "real" database solution.
Neither Oracle nor SQL Server supports these kinds of fields in their
table design nor in their query syntax.

So steer away while you still can :).

--
Jesse Houwing
jesse.houwing at sogeti.nl

Mark Rae

10/5/2009 9:48:00 PM

0

"Jesse Houwing" <jesse.houwing@newsgroup.nospam> wrote in message
news:%23jlG8HgRKHA.220@TK2MSFTNGP02.phx.gbl...

> So steer away while you still can :).

I couldn't agree more, but you're replying to the wrong post...


--
Mark Rae
ASP.NET MVP
http://www.m...

George Lee

10/6/2009 3:56:00 PM

0

Thanks for the reply and the confirmation. That was exactly the issue I was
questioning. The whole multivalued field is underdcocumented, and quite
frankly, it seems poorly considered. That article is the best one out there,
and while helpful, doesn???t really address the programmatic approach. Since
the this is unique to Access 2007, many of the ADO books don???t cover it.

The fact that a child ADO recordset could not be used is odd. In addition,
the SQL query only returns the bound values and the display values (as you
get with the same query when you do it in Access). I did come up with a
separate routine to manually extract the display values through a lookup.
It???s ugly code and it seems un-.NET-ish.


"Jesse Houwing" wrote:

> * Mark Rae [MVP] wrote, On 5-10-2009 22:06:
> > "George Lee" <GeorgeLee@discussions.microsoft.com> wrote in message
> > news:432DEC4A-B503-4CCB-94E8-7C6CDCD69AA7@microsoft.com...
> >
> > [please don't top-post]
> >
> >>>> How do you read/write multivalued fields in Access 2007 with ADO.NET
> >>>> C#?
> >>>
> >>> http://tinyurl.c...
> >>
> >> For the following code, the DAO approach would be to create another
> >> recordset
> >> based on the parent and loop through it. Is there an ADO equivalent?
> >>
> >> DataSet ds = new DataSet();
> >> myAdapter.Fill(ds);
> >
> > Not sure what you mean - that's ADO.NET...
> >
> >
>
> The query syntax can be found here:
> http://office.microsoft.com/en-us/access/HA1014929...
>
> When doing a select, you'll get all the values that were in the
> multivalued fields separated by ;.
>
> You will have to split them manually if you want to use them for a data
> binding scenario. There is no multi-valued field datatype that you can
> select for the column in a dataset.
>
> I'd recommend using a separate table instead of multi-valued fields.
> They're a kind of poor-mans-solution for database design. You won't be
> able to upgrade the database to any other "real" database solution.
> Neither Oracle nor SQL Server supports these kinds of fields in their
> table design nor in their query syntax.
>
> So steer away while you still can :).
>
> --
> Jesse Houwing
> jesse.houwing at sogeti.nl
>

Mary Chipman [MSFT]

10/7/2009 1:58:00 PM

0

On Tue, 6 Oct 2009 08:56:02 -0700, George Lee
<GeorgeLee@discussions.microsoft.com> wrote:

>Thanks for the reply and the confirmation. That was exactly the issue I was
>questioning. The whole multivalued field is underdcocumented, and quite
>frankly, it seems poorly considered. That article is the best one out there,
>and while helpful, doesn?t really address the programmatic approach. Since
>the this is unique to Access 2007, many of the ADO books don?t cover it.

Just to shed a little light on the "ill-considered" aspect --
multi-valued fields cause problems mainly because they are
non-relational, so there is nothing in ADO/ADO.NET that could have
anticipated working with them. They were created to make it easier to
work with Sharepoint from an Access UI, so viewed in that context they
work quite efficiently. If the primary purpose of the database is not
Sharepoint compatibility, then you're probably better off taking the
hit up front and normalizing the data in the multi-valued fields
before writing any code.

--Mary

George Lee

10/7/2009 9:23:00 PM

0



"Mary Chipman [MSFT]" wrote:

> On Tue, 6 Oct 2009 08:56:02 -0700, George Lee
> <GeorgeLee@discussions.microsoft.com> wrote:
>
> >Thanks for the reply and the confirmation. That was exactly the issue I was
> >questioning. The whole multivalued field is underdcocumented, and quite
> >frankly, it seems poorly considered. That article is the best one out there,
> >and while helpful, doesn???t really address the programmatic approach. Since
> >the this is unique to Access 2007, many of the ADO books don???t cover it.
>
> Just to shed a little light on the "ill-considered" aspect --
> multi-valued fields cause problems mainly because they are
> non-relational, so there is nothing in ADO/ADO.NET that could have
> anticipated working with them. They were created to make it easier to
> work with Sharepoint from an Access UI, so viewed in that context they
> work quite efficiently. If the primary purpose of the database is not
> Sharepoint compatibility, then you're probably better off taking the
> hit up front and normalizing the data in the multi-valued fields
> before writing any code.
>
> --Mary
>

Mary Chipman, the author? Excellent!

The Sharepoint context makes sense but I still have to work with these
files, and often don???t have the ability to redesign them since they are being
used by others for other purposes. Do do have any good code examples how to
access those fields programmatically?

Mary Chipman [MSFT]

10/8/2009 2:02:00 PM

0

On Wed, 7 Oct 2009 14:23:01 -0700, George Lee
<GeorgeLee@discussions.microsoft.com> wrote:

>The Sharepoint context makes sense but I still have to work with these
>files, and often don?t have the ability to redesign them since they are being
>used by others for other purposes. Do do have any good code examples how to
>access those fields programmatically?

I don't have any code handy, but it would involve basic string parsing
functions. I'd initiate a search for free code examples--I'm sure
you're not the first person who's had to parse multi-valued fields for
an app :-) How much data is involved? If the answer is "a lot" then
you'll not want to process large result sets, or you could be facing a
considerable perf hit. If that is the case, it might be a better
option to maintain two sets of the same data, one relational for your
..NET app, and the other for Access-Sharepoint users. You'd need to do
this in the back end database to ensure accuracy and consistency,
which isn't that easy to do in Access (no triggers). But at least
you'd be working with relational data, and your back end would convert
more easily to SQL Server when the time comes. Using Access/Jet/ACE as
the data store just doesn't work for most .NET scenarios.

--Mary