I have set Grid as my default page when I open the form. However, I can't
have multiple people accessing it because of "access is denied". Please see
it below.
1. select * from table1 into table c:\temp1.dbf
2. select * from table2 into table c:\temp2.deb
3. append from c:\temp1
4. select * from c:\temp2 order by number INTO CURSOR due
5. thisform.pageframe1.page5.grid1.RecordSource="due"
I know because of SQL select into table caused this problem. (I have tried
"delete file" but it will give me blank grid)
1. Is there any way to skip this sharing violation or by creating "view" can
solve sharing violation?
2. If I use into cursor1 and into cursor2, how can I consolidate them into
cursor3 and get sorted?
Thanks
Char
You can "Select ... Into Cursor ..." instead of "... Into Table ...".
Append From would still work if you'd "Append From Dbf('resultCursor')"
(instead of "Append From resultCursor").
(If you would want to create tables, better use a unique name each time,
and use the GetEnv('temp') folder since writing to C:\ is not allowed in
Vista and Windows7 and XP "Limited" accounts.)
However, you do not need that intermediate step since you can also get
the two-source-tables in one line using SQL Union.
And if you'd put all data into one table, you could use a Local View or
a CursorAdapter in order to make the result updatable.
hth
-Stefan
--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------
> I have set Grid as my default page when I open the form. However, I can't
> have multiple people accessing it because of "access is denied". Please see
> it below.
>
> 1. select * from table1 into table c:\temp1.dbf
> 2. select * from table2 into table c:\temp2.deb
> 3. append from c:\temp1
> 4. select * from c:\temp2 order by number INTO CURSOR due
> 5. thisform.pageframe1.page5.grid1.RecordSource="due"
Where exactly do you get the error "access is denied"?
I don't see, where it could happen, supposed C: is a lokal drive and not the
network drive where the other users write their temp tables.
As Stefan already wrote, you could make one line from your lines 1. to 4. (and
it would save you several other lines of code for cleaning up the temp files):
SELECT * FROM table1 UNION SELECT * FROM table2 INTO CURSOR due ORDER BY number
Regards
Bernhard Sander
The originally path was "c:\foxpro\" but since we have remote users running
this on the remote server thus there is no difference between C: or network
drive. (because it will get sharing violation when running on the remote
server) I was thinking to use path in user's document folder instead, in this
case, it won't get sharing violation. By the way, you mentioned that
Append From would still work if you'd "Append From Dbf('resultCursor')"
> (instead of "Append From resultCursor").
Could you give me an example of this code? if I wanted to use append from
cursor in some scenarios.
Thanks for your time and help.
Char
I still think you want it in this very scenario in order to avoid using
persistent tables <s>
Command Window example (watch for unintended wrapping):
CREATE CURSOR theTable (test i)
INSERT INTO theTable VALUES (3)
INSERT INTO theTable VALUES (5)
SELECT test, TRANSFORM(test) As cTest FROM theTable INTO CURSOR theCursor
CREATE CURSOR table2 (test i, cTest c(10))
APPEND FROM DBF('theCursor')
BROWSE
CREATE CURSOR table3 (test i)
INSERT INTO table3 (test) SELECT test FROM theCursor
BROWSE
hth
-Stefan
To expand on this one: although one should "never say never", it's
rarely useful to create temporary tables, or do a Select ... Into Table
... in VFP.
Because VFP has the "Cursor" feature already built-in, which does
exactly that - i.e. when you "Create Cursor ..." or "Select ... Into
Cursor ..." in one instance, and do the same in another instance on the
same machine using the same cursor names, VFP will create temp files for
you having unique names automatically. That is, it might even create the
cursor "files" in memory only to keep performance:
Create Cursor temp (test D)
? DBF('temp')
? File( Dbf('temp'), 1 )
(Perhaps one of the rare exceptions for the
never-ever-create-temp-tables rule is when you want two or more runtime
instances communicating with each other.)
Thanks for your help.
"Stefan Wuebbe" wrote:
> char wrote:
> > Hi Stefan,Bernhard
> >
> > The originally path was "c:\foxpro\" but since we have remote users running
> > this on the remote server thus there is no difference between C: or network
> > drive. (because it will get sharing violation when running on the remote
> > server) I was thinking to use path in user's document folder instead, in this
> > case, it won't get sharing violation.
>
> To expand on this one: although one should "never say never", it's
> rarely useful to create temporary tables, or do a Select ... Into Table
> .... in VFP.