tbl.enter_begin(t)....tbl.enter_end(t)

[enstorms]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

Thanks again, Cal. I haven't gotten around to completing my coding on the rest of the script. Have 10 more Month orders to do in the script. If I run into problems with this I'll let you know.
Ernie

[CALocklin]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

FWIW: I took out the .t. from begin and end and removed the xbasic_wait _for_idle statement and ran it and it added the records just fine.

Now that's interesting! It was only a wild guess on my part. (Here's a secret - that's how a lot of my solutions are found.)

I checked the Help file and found this very significant note:
Note : The Field_Rules_Flag parameter is only honored if the <TBL> pointer is the same pointer that a layout is using. For example,....
This doesn't tell me why it didn't work in your case but it does give me the feeling that it was trying to do something it couldn't do and therefore timing became more of an issue. But here's the real reason why this note is important....

I know that in my apps many of the situations where I'm entering data via xbasic are NOT entering it into the same table as the parent form. Also note that the above Note says, "the <TBL> pointer is the same pointer that a layout is using". It does not say, "the <TBL> pointer points to the same table as the layout is using". This is a BIG difference. The way I read this is that
tbl = table.open( "<TheSameTableastheForm>" )
won't do it because the "tbl" pointer does not actually point to the layout but
tbl = table.get( "<ATableintheForm>" )
or
tbl = table.current(n) (where "n" is the table number if not the parent)
or
tbl = parentform:tables:<ATableintheForm>.this
should work.

Edit: I think the original wording in the Help file would be more correct and/or more understandable like this:
... if the <TBL> pointer is pointing to a table in the same session as the layout is using ...Unfortunately even that isn't very clear so examples are the best way to understand this. Hopefully my examples are correct - no absolute guarantees on that.

[enstorms]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

Cal,
As always, thank you for a full explanation. Here again, I have read into the help files about the .t. in the begin and end statements that I needed it there to make sure my auto-increment fields got incremented properly. After further reading, I think I am way off base. I still don't fully understand what the purpose is for, i.e. field rules...., but don't think it is for making sure my auto fields get incremented.

I think there has to be something else going on......

I fully agree. I think I'll continue to play with it a bit and see what transpires.
Thanks again for the explanations.
Ernie

FWIW: I took out the .t. from begin and end and removed the xbasic_wait _for_idle statement and ran it and it added the records just fine.

[CALocklin]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

Now I'm new to Alpha, but having programming experience, shouldn't you have a CASE statement for each month? It looks like you have Case statements missing between your monthly processing.

I assume there will be once s/he gets January to work correctly.

[CALocklin]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

RE: tbl.add_blank_records(12)
This should work really well in a networked situation. User A adds 12 records. At the same point in time, user B adds 12 records. Then user A moves back 12 records. Will user A really end up where he started or could some of user B's records be intermixed? Not likely to happen often but what if it does? Or is there an "exclusive access" built into the add_blank_records function? I'd want to know before I implemented this but I don't see the answer in the Help file.

I think there has to be something else going on with the initial problem even though the part of the script we see looks OK. Otherwise, (a) running it with the Debug(1) should solve the timing issue and (b) running a WHILE loop to enter records would be likely to cause the same problem (and it's something I've done more than once with no problem) and (c) why would the "add_blank_records()" work if timing was a problem?

You might try eliminating the .T. in the enter_begin() unless there's some reason you really need it. Using this will try to enforce some additional field rules but normally you should be checking those before entering new data via xbasic anyway. Otherwise your script will just be generating errors that the users will have to decipher and resolve - or call you to fix - and this may result in bad data if the first few records get added but not the last ones.

FWIW: You probably don't need the .T. in the enter_end() either. The .T. in the enter_end() is only there to tell it 'yes, I want to save this record' but that's the default anyway. The only time I've used this is the rare situation when I'm doing development and don't want to actually save the record because it would negatively affect subsequent testing - i.e., I need the info in that record to NOT be there in order to test the routine and I may need to test the routine many times. Then, in most cases, I will set a variable at the beginning of the script so I can set it to .F. when I don't want to save anything or to .T. when I do want to save things. Once it goes into production, I usually remove all those variables but sometimes I just set them to .T. and leave them. Hmmm, I said "usually" but can only recall doing this once in about 15 years.

[enstorms]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

Thanks Stan. It didn't dawn on me that the tbl.add_blank_records(12) was adding them right then, all at once. That makes perfect sense. Appreciate the help in this.
Ernie

[Stan Mathews]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

Try it like this.

SELECT
	CASE vPlan_Month = "January"
		tbl.add_blank_records(12)
		[COLOR="Blue"]FOR i = 1 TO 11
			tbl.fetch_prev()
		NEXT i[/COLOR]
		[COLOR="Red"]'now we're back to first added record[/COLOR]
		tbl.change_begin(.t.)
		tbl.ap_sortno = 1
		tbl.ap_month = "January"
		tbl.ap_year = vPlan_Yr
		tbl.change_end(.t.)
		[COLOR="blue"]tbl.fetch_next() [/COLOR][COLOR="red"]'now on second added record[/COLOR]
		tbl.change_begin(.t.)
		tbl.ap_sortno = 2
		tbl.ap_month = "February"
		tbl.ap_year = vPlan_Yr
		tbl.change_end(.t.)
		[COLOR="blue"]tbl.fetch_next()[/COLOR][COLOR="red"]'now on third added record[/COLOR]
		'etc.........
END SELECT

[Stan Mathews]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

select
	    case vPlan_Month = "January"
                tbl.add_blank_records(12) [COLOR="Red"][B]' focus is now on the last record added[/B][/COLOR]
                tbl.change_begin(.t.) [COLOR="Red"]'begins changing that record[/COLOR]
			tbl.ap_sortno = 1
			tbl.ap_month = "January"
			tbl.ap_year = vPlan_Yr
			tbl.change_end(.t.)
	    	tbl.change_begin(.t.) [COLOR="red"]'haven't moved so we're changing the same record[/COLOR]
			tbl.ap_sortno = 2
			tbl.ap_month = "February"
 			tbl.ap_year = vPlan_Yr
			tbl.change_end(.t.) 
                etc......... [COLOR="red"]'etc[/COLOR]
	end select

[enstorms]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

Thanks, Angel. I am assuming I can add/change one right after the other????

	select
	    case vPlan_Month = "January"
                tbl.add_blank_records(12)
                tbl.change_begin(.t.)
			tbl.ap_sortno = 1
			tbl.ap_month = "January"
			tbl.ap_year = vPlan_Yr
			tbl.change_end(.t.)
	    	tbl.change_begin(.t.)
			tbl.ap_sortno = 2
			tbl.ap_month = "February"
 			tbl.ap_year = vPlan_Yr
			tbl.change_end(.t.) 
                etc.........
	end select

Ernie

[ewagner]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

Now I'm new to Alpha, but having programming experience, shouldn't you have a CASE statement for each month? It looks like you have Case statements missing between your monthly processing.

[ANGEL SANCHEZ]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

I used to have the same 8003 error when I used tbl.enter_begin().

Now I use tbl.change_begin() - tbl.change_end() like this:

	dim tabla as P
	tabla=table.get("control_dia")
	tabla.add_blank_records(1)
	tabla.change_begin(.T.)
	   tabla.EMPRESA_ID=XEMPRESA
	   tabla.UO_ID=XUO
	   tabla.FECHA_PRODUCCION=xfecha
	tabla.change_end(.T.)

ANGEL

[enstorms]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

Appreciate all the suggestions. I kind of had and inkling it might be timing, but still new to a5. I'll give this a try and see what happens. If no luck, I'll post a zip of the app for further review.
Thanks again.
Ernie

[Tom Cone Jr]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

If it's a timing issue, you can put the "processing" portion of your script in a function. The script will halt each time the function runs, and will resume only after the function has completed. Here's a quick and dirty example that illustrates the technique.

tbl = table.open("customers")

enter_new(tbl,"Bob",1)
enter_new(tbl,"Sam",2)
enter_new(tbl,"Tom",3)

tbl.close()
	
Function enter_new as L (ptr as p, cust as C, sort as n)
	ptr.enter_begin(.t.)
	    ptr.name = cust
	    ptr.idnum = ltrim(str(sort))
	    ptr.enter_end(.t.)
end function

[Scott Emerick]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

I agree with Tom that it is a timing issue. Try something simple like placing xbasic_wait_for_idle() between your tbl.enter_end and tbl.enter_begin

My guess is that your first tbl.enter_end did not have time to finish before you started entering again.

Hope this helps ...

Scott

[Tom Cone Jr]

Re: tbl.enter_begin(t)....tbl.enter_end(t)

This would be easier if you showed the entire script and furnished a sample database.

It looks like a timing issue.

But...

Does your script check the mode of the table before it runs? You can't begin a new record if the table is in CHANGe or ENTER mode already.