Quote:


And, as Carl pointed out, Sesame does retain the capability, and allows the programmer the choice.

Supporting XLookup (as opposed to @XLookup) was not something that the author of Q&A 5.0 and SBasic (Andreas Goebels) wanted to do. Directly writing to LEs without opportunity for data integrity checking is highly dangerous and should never be done. It was discouraged in Q&A (as you pointed out) and is discouraged in Sesame. Without variables, Q&A Basic was forced to use additional form fields to hold temporary variables. That, of course, is no longer necessary, and eliminates the need to ever use XLookup (as opposed to @XLookup).

In any case, XLookupAll, XLookupSourceList, and XLookupSourceListAll, provide any number of field values to be returned from an external database. Using XLookupSourceListAll, you can actually return the entire external database, if you choose.

Also, since the X family of commands accept search specs as keys, you can also return a range of values, or find close matches.

Mark -

I thought I was following everything here, but I got a bit confused after your last comment.

Quote:


Are you saying that I can write one programming statement for xlookup to retrieve (as many as) 20 (or perpaps more) values and insert them in the appropriate fields?

Or (as carl aslo said),: Quote:
do I need to learn StringArrayfunctions (which I haven't begun to look at yet) and write additional programming for it to happen?

If it's the latter then, perhaps sample programming would be helpful. 

Certainly I would still like the convenience we had with the one programming statement (as in Q&A) which I used for years and never encountered a single problem.

Should you communicate with Andeas, by the way, please give him my best regards.

Thanks!

Quote:

Oh, okay, now I see why you were talking about the lock status of AppB. It makes sense when you explain it that way.

Quote:


Its been a little while. I owe him a trip to Germany.

The more that is written the more confused I get.  Up until now I have only heard the term client/server used in conjunction with networked systems where the server contained the "permanent" files and the client (a "remote" user) either accessed those files remotely ... or a copy was made on the client's machine (while other people could have access to the server's database but could not change anything) and the client saved the changes and it was copied back to the server (OR SOMETHING TO THAT EFFECT).

It is not important (for me) to understand all this.  What it sounds like your saying - and this is the part that I do want to know - is that when I a single user on a single machine open my database - there comes into excistence both a client and server?

Yes, no, maybe, what??

Thanks!

Mark -

Quote:


He's already there, why would he need another trip?  Ohhhh, you must mean visit (from you).  lol

OK, kidding aside, back to this issue (which I hope won't be forgotten in this cross-discussion of a simple lookup failure and the topic of multiple lookups/saves).

First, of all, Carl was referring to Version 1.1 of the Programmer's Guide when he referred to "page 90."  The only coding provided there however is how to do the lookup.  It is very clear and straight-forward and easy to do .... so in the absence of a simple xlookup with many returns into the associated fields, this is certainly a help.

The coding example I would like to see is the use of stringarrays (Greek to me) that would be used to take the returned fields - to continue with your example - of Last Name, First Name, City and get each value into the appropriate LED fields, also named (but perhaps in a different order) of:  FirstName, LastName and City.

Also, I can't see why a lot of weight (if any) should be given to the programmer's "liability" for not screwing up his/her own database.

It seems to me that even with the use of arrays, I could conceivably wipe out critical data etc. etc.  (I'm not sure whether I could enter a text field into a numeric one or vice versa with string arrays).

Also, look at the risk in multiple clear statements (where I could accidentally wipe out a critical field) or a mass update where I could literally screw up every single field in there.  So I think (so long as Lantica provides appropriate "cautions" .. and certainly you do ... the individual Sesame programmers need to take the "risk" into account and decide if it's worth it.  Personally, I always like to have the option of "ease of use."

Now, assuming we never get the xlookup that at least a few of us (if not more) want, couldn't Andreas develop a utility program that will do the multiple x-lookups when converting Q&A to Sesame?  (He's a very clever guy). 

Anyhow, I want to be clear that having one statement to place lookup values where I want them is certainly not as important as some other things that are needed.  But, still, it would be nice to have and with appropriate caution to the the user - the user could then decide whether it's worth the risk or not.

After all this cross-talk I do hope my original "issue" will have some light shed on it.  If not, it can go in the "life's never-to-be answered questions" file.  lol

Quote:

Yeah. Lantica and Hammer have asked Andreas over the ocean many times. The last time he was here, he insisted that we need to come to him next time.
Quote:

String arrays are pretty easy and save a lot of coding.
Quote:

Its not the liability, its the inability to prevent it that concerns us. In Q&A, you had no choice but to either do a blind copy from XLookup, or create an "extra" field on your form with no other purpose than to catch the value of an @XLookup. A blind copy provides no way to prevent damage, even if you know to do so. Using an extra field bloats the database and creates opportunities for corruption and error. It must also be hidden from the end user.

Because it provides no way to check for errors, in execution or in data, even if allowed, a blind copy should never be used. That gives the careful programmer no choice but to use an "extra" field.
Quote:

Of course you could, but you don't have to. Using variables (especially) you have the opportunity to check for both data and execution errors before your critical LEs are overwriiten. In addition, you have an opportunity to filter, manipulate, and examine the data you are working with. It is not a blind copy. You can check the value before you write it to the LE.
Quote:

With clear, you are writing a known value - it is not a blind copy.
Quote:

Again, with a mass update, you can see the value you are going to write before you write it to the LE. It is not a blind copy like XLookup.
Quote:

There is no reason to assume that. As I mentioned, I would like to put it in to Q&A compatibility reasons.
Quote:

Andreas could (no doubt) do that, but it would be much more efficient (for everybody, machines and people) to use a single XLookupSourceList.
Quote:

Like I said, I want it for compatibility reasons. I still don't recommend its use. I have a large collection of Q&A databases (~6000). I collected them while we were working on the translator. All of them were in use in the real world at some time. Almost every single one of them exhibited data corruption (the application was working perfectly but the data was incorrect by type). Almost all of them had structural corruption. This was usually minor but did create "bad" records (that could return values to an XLookup). More than half of them had profound structural corruption, and while the app would run (and give little or no indication that it was failing), it was actually failing on a significant portion of the application. Many (~10%) had ongoing corruption, where using the database was actually causing it to destroy data. Many of the worst were unreadable in any program.

A blind copy can easily propogate incorrect or corrupt values, and provides no means of determining if it has done so. Love, but do not trust, your data.
Quote:

I haven't looked (yet) to see what is going on with your specific situation (wherein an XLookup failed until the second server was dropped), but assuming you want a remedy, you can either hold off on the XLookup until you are finished using the second server (since you are just one user) or run both clients on a single server using client/server (which should be your end goal if you are ever intending to have multiple users later).